Skip to content
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

Windows build failure: undefined reference to `_setjmp' #192

Open
kyleconroy opened this issue Sep 21, 2023 · 7 comments
Open

Windows build failure: undefined reference to `_setjmp' #192

kyleconroy opened this issue Sep 21, 2023 · 7 comments

Comments

@kyleconroy
Copy link
Contributor

kyleconroy commented Sep 21, 2023

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/[email protected]/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
Copy link
Contributor Author

kyleconroy commented Sep 21, 2023

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

@alexcrichton
Copy link
Member

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
Copy link
Contributor

guregu commented Sep 23, 2023

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

@alexcrichton
Copy link
Member

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
Copy link
Contributor

guregu commented Sep 25, 2023

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

@alexcrichton
Copy link
Member

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
Copy link
Contributor

guregu commented Oct 22, 2023

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants