Uh oh!
There was an error while loading. Please reload this page.
ci(windows): fix CI failure on x86_64-pc-windows-gnu - #3849
Conversation
x86_64-pc-windows-gnux86_64-pc-windows-gnu0dc8f78 to
99a4df7Comparedjc
commented
May 31, 2024
Thanks for picking this up! |
@djc Sorry this PR is not ready yet. I thought it was fixed but obviously I wasn't looking at the right direction 😓 @mati865 do you happen to have any idea on this one? The context is that our Windows/GNU CI has been failing since merging #3367 and we have now idea why this is the case 🙏 |
mati865
commented
May 31, 2024
Looks like a linker crash to me. LTO is unrelated because Rust doesn't use linker's LTO (unless you explicitly enable it: https://doc.rust-lang.org/rustc/linker-plugin-lto.html). I can only guess what is crashing it but I'd bet |
475a043 to
f32b890Compare
@mati865 Thanks for helping out! Unfortunately, now the error is different, but the build is still a failure, am I doing anything wrong? = note: Warning: corrupt .drectve at end of def file Warning: corrupt .drectve at end of def file C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: warning: C:\Users\runneradmin\.cargo\registry\src\index.crates.io-6f17d22bba15001f\windows_x86_64_gnu-0.42.2\lib/libwindows.a(ntdll_dll_s00014.o): local symbol `' has no section collect2.exe: error: ld returned 1 exit status |
mati865
commented
Jun 1, 2024
I have no idea what it means but maybe this section causes the crash with |
0042d4c to
821d0f0Compare@mati865 I just tried with error: linking with `rust-lld.exe` failed: exit code: 1 |
= note: "rust-lld.exe" "-flavor" "gnu" "--dynamicbase" "--disable-auto-image-base" "-m" "i386pep" "--high-entropy-va" "C:\\Users\\runneradmin\\.rustup\\toolchains\\stable-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcVUMshG\\symbols.o" "D:\\a\\rustup\\rustup\\target\\x86_64-pc-windows-gnu\\debug\\deps\\rustup_init-02e6c105cc009354.14p56amfjwwsn5jm.rcgu.o" "D:\\a\\rustup\\rustup\\target\\x86_64-pc-windows-gnu\\debug\\deps\\rustup_init-02e6c105cc009354.17ib23qhpn1v4l6i.rcgu.o" "D:\\a\\rustup\\rustup\\target\\x86_64-pc-windows-gnu\\debug\\deps\\rustup_init-02e6c105cc009354.19e13oqkyvw78abj.rcgu.o" "D:\\a\\rustup\\rustup\\target\\x86_64-pc-windows-gnu\\debug\\deps\\rustup_init-02e6c105cc009354.1d01k4kqg3wx0lrc.rcgu.o" "D:\\a\\rustup\\rustup\\target\\x86_64-pc-windows-gnu\\debug\\deps\\rustup_init-02e6c105cc009354.1eteqsfeqh29lh61.rcgu.o" "D:\\a\\rustup\\rustup\\target\\x86_64-pc-windows-gnu\\debug\\deps\\rustup_init-02e6c105cc009354
= note: lld: error: unable to find library -lpsapi lld: error: unable to find library -lpowrprof lld: error: unable to find library -lws2_32 lld: error: unable to find library -lcrypt32 lld: error: unable to find library -lbcrypt lld: error: unable to find library -ladvapi32 lld: error: unable to find library -ladvapi32 lld: error: unable to find library -lkernel32 lld: error: unable to find library -lole32 lld: error: unable to find library -loleaut32 lld: error: unable to find library -lntdll lld: error: unable to find library -lkernel32 lld: error: unable to find library -ladvapi32 lld: error: unable to find library -lkernel32 lld: error: unable to find library -lntdll lld: error: unable to find library -luserenv lld: error: unable to find library -lws2_32 lld: error: unable to find library -lkernel32 lld: error: unable to find library -lws2_32 lld: error: unable to find library -lkernel32 lld: error: too many errors emitted, stopping now |
mati865
commented
Jun 2, 2024
@rami3l LLD should be used like on Unix systems, via |
rami3l
commented
Jun 2, 2024
Yes, I did exactly that in https://github.com/rust-lang/rustup/actions/runs/9321950575/job/25661988047, but that... still looks like a GNU ld error? |
mati865
commented
Jun 2, 2024
Yeah, for some reason LLD was not used. Locally running with MSYS2 (ucrt64 env) I got slightly different error couple time: but all new builds since then do pass (doing Upon trying https://github.com/niXman/mingw-builds-binaries/releases/tag/13.2.0-rt_v11-rev0 that you install via chocolatey it seems to reproduce every time. Also LLD didn't help, there is probably some incompatibility in how GCC and Clang generate the sections: So the solution here would be to use more recent tools, for an example using MSYS2 but anything modern should work. |
b6569c4 to
fe28c8cCompare5346ef9 to
5823121CompareI suspect we've been using the bundled (sigh) mingw all along (!) and have encountered something similar to actions/runner-images#5459. ... and the version so far is: ... which explains everything.
>Get-Command x86_64-w64-mingw32-gcc
CommandType Name Version Source ---------------------------- Application x86_64-w64-mingw32-gcc.exe0.0.0.0 C:\mingw64\bin\x86_64-w64-mingw32-gcc.exeUpdate: After trying another installer, it finally worked! Thanks a lot for your pointers @mati865 and @ChrisDenton! |
6dcf9ef to
3005c8dCompare
Currently, the
masterCI fails onx86_64-pc-windows-gnuonThis PR tries to address this issue while moving away from the previously hardcoded MinGW version (6.3.0 from 2017) at the same time.
Concerns
Should we keep theI guess we should, at least for the moment.x86_64-pc-windows-gnuCI enabled even on PRs?