undefined: wasmtime.Wat2Wasm on windows and macos (darwin)

[Eyzic]

When compiling with GOOS and GOARCH flags, compilation fails when GOOS is windows or darwin, but succeeds when it is linux.
I am running the go build command from linux (tried both fedora-41 locally and ubuntu-latest through build pipeline).

Issue

Running:
GOOS=windows GOARCH=amd64 go build -o test
GOOS=darwin GOARCH=amd64 go build -o test

Produces:
undefined: wasmtime.Wat2Wasm

Conditions

In the file it complains about, there is an import "github.com/bytecodealliance/wasmtime-go/v29" and a function call wasmBytes, err := wasmtime.Wat2Wasm(wat).

Not an issue

Running:
GOOS=linux GOARCH=amd64 go build -o test

Works fine without any compilation error.

---

Seems very strange to me that GOOS would affect something becoming undefined, so I'm suspecting something might be wrong? If there is an explanation for this or I am missing something, then perhaps it would be good to add that to the readme file. If I am the only one with this issue, do let me know.

Workaround (In case someone else has this issue)

I managed to work around it by not cross-compiling and adding flag CGO_ENABLED=1. That made it work of macos.
For windows I also needed to download MinGW and set CC=x86_64-w64-mingw32-gcc and CXX=x86_64-w64-mingw32-g++

Leaving that here in case it helps anybody else.

[alexcrichton]

This module requires cgo unconditionally as Wasmtime isn't written in Rust. Cgo I believe then requires a native C toolchaing for the target platform to link/etc. In that sense cross-compiling is not easy as it requires acquiring a toolchian along the lines of x86_64-w64-mingw32-gcc for each platform. I don't know how to compile for macOS from Linux, for example. Your fix of installing x86_64-w64-mingw32-gcc for Windows is the only way I know of how to compile to Windows from Linus.

[Eyzic]

Thank you for taking time. Do you know why it results in undefined? I'm just curious.

Do you think it would be worthwhile to mention in the readme? I saw in another issue that you did not remember why you wrote about CGO_* flags. Could this have been what you were thinking about?

[alexcrichton]

I'm not sure myself, but I'm also not that familiar with cross-compilation in Go either. My guess though is that it's probably due to toolchain configuration rather than this respository itself, but I would by no means be certain in concluding such either.

If there's a fix to apply that seems reasonable add to the readme yeah, but I think it'd be good to fully understand the fix when documenting it too