Windows build failure: undefined reference to `_setjmp'

[kyleconroy]

I build wasmtime-go using Github Actions. The latest release of their Windows runner upgraded mingw-w64 from 11.2.0 to 12.2.0 and it appears to have broken things.

https://github.com/actions/runner-images/releases/tag/win22%2F20230918.1

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/runneradmin/go/pkg/mod/github.com/bytecodealliance/wasmtime-go/v12@v12.0.0/build/windows-x86_64/libwasmtime.a(helpers.o):helpers.c:(.text$wasmtime_setjmp_12_0_0+0x26): undefined reference to `_setjmp'

Full logs are available here

[kyleconroy]

I've confirmed that downgrading to mingw 11.2.0 fixes the issue. sqlc-dev/sqlc#2757

[alexcrichton]

My guess is that MinGW changed ABIs of the setjmp function, but does the 13.0.0 release work for you? That was built more recently in CI so I believe that Wasmtime 12 and prior use MinGW 11.2 and 13 should use 12.2

[guregu]

Unfortunately v13 seems to have the same issue: example failed run.
But the workaround in #192 (comment) helps v13 as well (thanks!).

[alexcrichton]

CI for this repository is failing with the same issues as above. Interestingly though they're also failing with

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\go-link-1064439917\000030.o: in function `_cgo_preinit_init':
\\_\_\runtime\cgo/gcc_libinit_windows.c:30: undefined reference to `__imp___iob_func'
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\go-link-1064439917\000030.o: in function `x_cgo_sys_thread_create':
\\_\_\runtime\cgo/gcc_libinit_windows.c:60: undefined reference to `__imp___iob_func'
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\go-link-1064439917\000030.o: in function `x_cgo_notify_runtime_init_done':
\\_\_\runtime\cgo/gcc_libinit_windows.c:101: undefined reference to `__imp___iob_func'
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\go-link-1064439917\000031.o: in function `x_cgo_thread_start':
\\_\_\runtime\cgo/gcc_util.c:18: undefined reference to `__imp___iob_func'
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\go-link-1064439917\000032.o: in function `_cgo_sys_thread_start':
\\_\_\runtime\cgo/gcc_windows_amd64.c:31: undefined reference to `__imp___iob_func'

It looks like the 13.0.0 release happened right at the time the github runner upgrade was rolling out, so the CI passed here but has failed ever since. I don't know what's going on with __imp___iob_func but it seems like things are compiled with mismatched versions of MinGW and/or MSVC. I'm not sure what the source of the problems here is though and why Wasmtime's CI, for example, is passing but this repository isn't.

The 13.0.0 artifacts for Wasmtime itself were produced on an older version of the github runner (I think). The dev artifacts, however, are more recent and should be produced by the newer MinGW compiler version. In #194 that "fixed" the _setjmp issue but there's still the __imp__iob_func issues which I don't know what to do with.

[guregu]

This might be related: golang/go#57455 (comment)
Adding the -a flag to the go build or go test invocation could help.

[alexcrichton]

According to #194 and the linked Go issues I've deduced:

• For __imp___iob_func that's fixed by Go 1.20+ and/or go build -a
• For _setjmp that's "fixed" by keeping the toolchain in use by Go in sync with the toolchain that produced libwasmtime.a. This means, for example, that current GitHub actions requires the dev release of Wasmtime using the same GitHub actions image.

So @kyleconroy I think your issue is indeed to keep MinGW toolchains in sync, and my issue is to do that and upgrade Go.

As to the technical matter at hand I didn't realize that setjmp would require keeping MinGW toolchains in sync. We should probably find an alternative to doing that or sone that doesn't rely on libc functionality but instead stuff built into kernel32.dll or similar.

[guregu]

The latest release looks like it fixed this issue (successful build without workaround). Nice!