-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spurious failures on AppVeyor due to ar.exe errors #40546
Comments
The first hit on Google is quite ominous. My preference for an attempt to fix this would be to switch to ninja as it's likely just flat out more reliable than makefiles on MinGW |
Oh also we're going to want to switch the MSVC build to Ninja regardless, so we'll have it available anyway eventually on the bots. |
I've met it few times with MSYS2 and (almost?) always it was caused by CL RF line endings or too long paths or file names. |
I have a suspicion that MinGW's make is the cause of rust-lang#40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes rust-lang#40546 for real, but this is my current best shot at closing it out, so... Closes rust-lang#40546
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of #40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes #40546 for real, but this is my current best shot at closing it out, so... Closes #40546
appveyor: Use Ninja to build LLVM on MinGW I have a suspicion that MinGW's make is the cause of rust-lang#40546 rather than anything else, but that's purely a suspicion without any facts to back it up. In any case we'll eventually be moving the MSVC build over to Ninja in order to leverage sccache regardless, so this commit simply jumpstarts that process by downloading Ninja for use by MinGW anyway. I'm not sure if this closes rust-lang#40546 for real, but this is my current best shot at closing it out, so... Closes rust-lang#40546
Unfortunately it looks like this is not fixed |
Another attempt to fix this |
In debugging rust-lang#40546 I was able to reproduce locally finally using the literal toolchain that the bots were using. I reproduced the error maybe 4 in 10 builds. I also have the 6.3.0 toolchain installed through `pacman` which has yet to have a failed build. When attempting to reproduce the bug with the toolchain that this commit switches to I was unable to reproduce anything after a few builds. I have no idea what the original problem was, but I'm hoping that it was just some random bug fixed somewhere along the way. I don't currently know of a technical reason to stick to the 4.9.2 toolchains we were previously using. Historcal 5.3.* toolchains would cause llvm to segfault (maybe a miscompile?) but this seems to have been fixed recently. To me if it passes CI then I think we're good. Closes rust-lang#40546
@arielb1 yes I think that's the best solution here. @mati865 ah we don't want to rely on the msys packages as well b/c we can't pin versions. They'll change from under our feet which runs the risk of breaking the build which we'd prefer to avoid. @crlf0710 this isn't related to LLVM, it's related to the gcc/gdb toolchain versions |
This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes rust-lang#40546
…enkov appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes rust-lang#40546
This commit sort of brings back rust-lang#40777 by upgrading back to 6.3.0. While investigating rust-lang#40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for rust-lang#40184 contained in rust-lang#40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes rust-lang#40546
appveyor: Upgrade to gcc for mingw 6.3.0 This commit sort of brings back #40777 by upgrading back to 6.3.0. While investigating #40546 it was discovered that 6.3.0 appears to not spurious fail in the same way that 6.2.0 does (which we're currently using). The workaround for #40184 contained in #40777 did not work so this commit also contains a different workaround for the gdb issue. We will not download the 6.2.0 version of gdb and use that instead of the default version that comes with 6.3.0. I'm going to optimistically say... Closes #40546
This is, unfortunately, still a problem. See #41580 (comment). |
Possibly a false alarm. #41580 is targeting the beta branch, which presumably does not have the fix for this failure, in which case it's "normal" for it to fail spuriously. Will leave open for someone to confirm, though. |
@Mark-Simulacrum ah yeah I think we're ok, #41420, the fix, is only on master not on beta |
I've previously been classifying these errors under #40240 but now I'm thinking that's incorrect, I suspect these are totally separate errors.
https://ci.appveyor.com/project/rust-lang/rust/build/1.0.2397
The text was updated successfully, but these errors were encountered: