After a large update, my windows build with the gnu toolchain fails. The whole thing builds (and tests) properly on linux. When trying to build locally on windows, the failure is slightly different, and since the github action is the important thing, I'll focus on that.
The build log is pretty long, I'll cite below, but here's the full thing.
Note that the profile full-opt is just release plus lto = "thin" and codegen-units = 1. The log shows that no cache is restored so that should not be the cause of the error.
The problem seems to be the linker: error: linking with x86_64-w64-mingw32-gcc failed: exit code: 1.
There are a lot of warnings. Googling said it'd be safe to ignore them, so I wouldn't know what to do about them
The "real" error is a repeat of
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\RUNNER~1\AppData\Local\Temp\rustcWhmeQT\libfltk_sys-9d8b5b3d80267d48.rlib(pngerror.c.obj):pngerror.c:(.text$fltk_png_safe_execute+0x3a): undefined reference to `_setjmp'
collect2.exe: error: ld returned 1 exit status
I've found some issues on rust that talk about a wrong linker being picked up, but there did not seem to be a solution. I've used choco uninstall mingw to get rid of that compiler, but the error persisted with some other path for ld.exe
I've used [windows-2019] before, but that was no different.
The error seems to be from compiling fltk-sys. My master branch still compiles (that doesn't have all those large code changes), and this also runs on fltk. I could not find any issues related to setjmp here.
Obligatory: I'm not using any unsafe in my own code.
I'd appreciate any pointer. I've tried some things to no avail, but I could also not find something else. If I should provide more data, let me know
Are you using the fltk-bundled flag?
I’ve seen a similar error which was due to libc incompatibility between the libc used to build the prebuilt fltk binaries (msvcrt for gnu) and the host libc you’re building against (maybe ucrt).
So, as far as I can see, the host libc in a github runner should be the one that comes with the system, as long as I don't muck with it, right? And seeing the exact same version compile fine on my master, but not on my "new" branch... that should not be it, right? Or could one of the new dependencies somehow muck with that? How would I find out?
There are no such thing as “host libc” on Windows. Historically each release of MSVC had it's own, unique, libc (and different versions of Windows carried different number of these), these days all latest version include the same half-dozen of them. But half-dozen is still not one.
You need to reproduce the issue and look on which variants of libc different C dependencies expect. The ones built from sources should be fine, but anything “bundled” may be a problem.
It might be a different crate linking an incompatible libc to that of the prebuilt fltk binary. setjmp is part of the C runtime, so things point to msvcrt vs ucrt issue (especially when it comes to the gnu toolchain). For windows-gnu, the prebuilt fltk binary is built using the mingw compiler and links the msvcrt runtime.
The C++ standard libs are usually part of the vc-redist where msvc is concerned (which microsoft used to ship whenever a new version of msvc came out), but fltk doesn’t link the C++ standard library.
Trying to figure which dependency (or its transitive dependencies) is the cause might be difficult. You can try disabling the fltk-bundled flag or building using msys2 mingw (since it should be more isolated).
Bloody hell, you're such a hero, @MoAlyousef, a thousand thanks!
For the record, downgrading the runner to windows-2019 did not solve the issue, but downgrading mingw did the trick. Removing the fltk-bundled flag did not resolve it either, but the problem seems to have shifted somewhat (the linker still errors, but it's not clear to me what the error really is).