cmd/link: cross compile from MacOS to Windows with CGO_ENABLED=1 and -buildmode=c-archive not working

[awsong]

What version of Go are you using (go version)?

$ go version
go version go1.20.2 darwin/arm64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/wsong/Library/Caches/go-build"
GOENV="/Users/wsong/Library/Application Support/go/env"
GOEXE=".exe"
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/wsong/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="windows"
GOPATH="/Users/wsong/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20.2"
GCCGO="gccgo"
GOAMD64="v1"
AR="x86_64-w64-mingw32-gcc"
CC="x86_64-w64-mingw32-gcc"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/wsong/Development/test/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/var/folders/lr/s8_5072s6cs602ksv8tv5myh0000gn/T/go-build2849677897=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I have following files in my folder:

example/ go.mod   test.c   test.go
./example:
main.c

wsong@Work: ~/Development/test $ cat go.mod
module test

go 1.20
wsong@Work: ~/Development/test $ cat test.c
// Functions exported by Go.
extern int Test();

int test() {
	Test();
	return 0;
}
wsong@Work: ~/Development/test $ cat test.go
package main

//#include "errno.h"
import "C"

func main() {}

//export Test
func Test() C.int {
	return 0
}

wsong@Work: ~/Development/test $ cat example/main.c 
extern int test();

int main(void) {
	test();
	return 0;
}

I run go build like this:

CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-gcc GOOS=windows GOARCH=amd64 go build -v -a -buildmode=c-archive .

Then go into example folder and run:

x86_64-w64-mingw32-gcc main.c ../test.a

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

[heschi]

cc @golang/compiler

[cherrymui]

What version of C toolchain do you use? Thanks.

cc @thanm

[awsong]

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) 

[thanm]

@awsong Thanks for the report.

If you could dump out the symbols from your test.a and post it here, that would be helpful, e.g. something like

$ CGO_ENABLED=1 go build -buildmode=c-archive 
$ llvm-objdump-14 -t test.a | fgrep test | fgrep .text 
0000000000011200 l     F .text	00000000000000ef runtime.gcTrigger.test
000000000003ade0 l     F .text	00000000000001f0 runtime.testAtomic64
0000000000000000 g     F .text	000000000000000c test
$

[awsong]

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

[thanm]

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.

[thanm]

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:

$ ARPATH=`x86_64-w64-mingw32-gcc --print-prog-name ar`
$ CGO_ENABLED=1 CC=x86_64-w64-mingw32-gcc AR=x86_64-w64-mingw32-gcc GOOS=windows GOARCH=amd64 go build -ldflags="-extar=$ARPATH" -buildmode=c-archive .
$

Problem here is that the Go linker is invoking the system "ar" instead of the cross-compiler's "ar".

[awsong]

Verified that the workaround works on my system.

Thanks

[gopherbot]

Change https://go.dev/cl/479775 mentions this issue: cmd/link: use "ar" path derived from querying CC for -buildmode=c-archive