-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
cmd/link: cross compile from MacOS to Windows with CGO_ENABLED=1 and -buildmode=c-archive not working #59221
Comments
cc @golang/compiler |
What version of C toolchain do you use? Thanks. cc @thanm |
It's mingw-w64 from homebrew, on M1 Mac. wsong@Work: ~/Development/test/example $ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/mingw-w64/10.0.0_5/toolchain-x86_64/libexec/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: ../configure --target=x86_64-w64-mingw32 --with-sysroot=/opt/homebrew/Cellar/mingw-w64/10.0.0_5/toolchain-x86_64 --prefix=/opt/homebrew/Cellar/mingw-w64/10.0.0_5/toolchain-x86_64 --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --enable-languages=c,c++,fortran --with-ld=/opt/homebrew/Cellar/mingw-w64/10.0.0_5/toolchain-x86_64/bin/x86_64-w64-mingw32-ld --with-as=/opt/homebrew/Cellar/mingw-w64/10.0.0_5/toolchain-x86_64/bin/x86_64-w64-mingw32-as --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-zstd=no --disable-multilib --disable-nls --enable-threads=posix Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.2.0 (GCC) |
@awsong Thanks for the report. If you could dump out the symbols from your
|
wsong@Work: ~/Development/test $ x86_64-w64-mingw32-objdump -t test.a | fgrep test | fgrep .text wsong@Work: ~/Development/test $ x86_64-w64-mingw32-objdump -t test.a | fgrep test In archive test.a: [228](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000012900 runtime.gcTrigger.test [697](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x000000000003e620 runtime.testAtomic64 [1544](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000053678 runtime.test_z64 [1545](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x0000000000053670 runtime.test_x64 [1569](sec 4)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x00000000000534a9 runtime.testingWER [ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x0000000000000000 test.cgo2.c [ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x0000000000000000 test.c [ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x0000000000000000 test |
Thanks. No red flags there, not immediately sure what the issue is. I'll work on setting up a test machine of some sort to see if I can repro. Stay tuned. |
OK, I think I see what the issue is. I'll send a CL tomorrow morning. If you need a workaround for the time being, you can do this:
Problem here is that the Go linker is invoking the system "ar" instead of the cross-compiler's "ar". |
Verified that the workaround works on my system. Thanks |
Change https://go.dev/cl/479775 mentions this issue: |
…mode When external linking with -buildmode=c-archive, the Go linker eventually invokes the "ar" tool to create the final archive library. Prior to this patch, if the '-extar' flag was not in use, we would just run "ar". This works well in most cases but breaks down if we're doing cross-compilation targeting Windows (macos system "ar" apparently doesn't create the windows symdef section correctly). To fix the problem, capture the output of "cc --print-prog-name ar" and invoke "ar" using the path returned by that command. Fixes golang#59221. Change-Id: I9de66e98947c42633b16fde7208c2958d62fe7cc Reviewed-on: https://go-review.googlesource.com/c/go/+/479775 Reviewed-by: Cherry Mui <cherryyz@google.com> Run-TryBot: Than McIntosh <thanm@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Hmm, I've had to send a revert for https://go.dev/cl/479775 since it causes a failure on our |
Change https://go.dev/cl/480675 mentions this issue: |
Intercept the "--print-prog-name=ar" flag in the clang wrapper and return "ar" from the system path, as opposed to the "ar" selected by clang. This is needed to avoid bypassing the ar wrapper installed in /var/root/bin, which is the one we want. Updates golang/go#59221. Change-Id: I907a6d6be2e6439901b36d6f7f8669939fd82e94 Reviewed-on: https://go-review.googlesource.com/c/build/+/480675 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
Change https://go.dev/cl/488576 mentions this issue: |
Hey @thanm, any update here? Do you still plan to do this for Go 1.21? Thanks. |
I've moved to backlog. The main sticking points here are the problems with the ios correllium builders-- needs more investigation as to why the change doesn't work with their custom wrappers. |
If we want to do something for this cycle, we could do it only for Windows. |
Change https://go.dev/cl/592375 mentions this issue: |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
I have following files in my folder:
I run go build like this:
Then go into example folder and run:
What did you expect to see?
a.exe is generated.
What did you see instead?
/opt/homebrew/Cellar/mingw-w64/10.0.0_5/toolchain-x86_64/bin/x86_64-w64-mingw32-ld: /var/folders/lr/s8_5072s6cs602ksv8tv5myh0000gn/T//ccHcSIoc.o:main.c:(.text+0xe): undefined reference to `test'
collect2: error: ld returned 1 exit status
The text was updated successfully, but these errors were encountered: