cmd/link: statically compiling windows/amd64 binary on linux fails on 1.5

[jessfraz]

Previously on go 1.4.3 this used to work:

export CC=x86_64-w64-mingw32-gcc
export CGO_ENABLED=1
export GOOS=windows
export GOARCH=amd64

go build -o bundles/1.9.0-dev/cross/windows/amd64/docker-1.9.0-dev.exe -a -tags 'netgo static_build sqlite_omit_load_extension apparmor selinux daemon journald btrfs_noversion libdm_no_deferred_remove' -installsuffix netgo -ldflags '-w -extldflags "-static" -extld=x86_64-w64-mingw32-gcc' ./docker

Now when trying to run the same thing I get:

# github.com/docker/docker/docker
/usr/local/go/pkg/tool/linux_amd64/link: running x86_64-w64-mingw32-gcc failed: exit status 1
/usr/bin/x86_64-w64-mingw32-ld: i386 architecture of input file `/tmp/go-link-623415307/000000.o' is incompatible with i386:x86-64 output
collect2: error: ld returned 1 exit status

That's a super gross command I know, but I can make a small go program and try to compile statically for windows on linux and see the same thing.

[jessfraz]

Also this is go 1.5.1

[davecheney]

Two questions

1. Isn't cross compilation always statically linked, ie, no cgo by default unless you work really hard at it
2. The error message seems to be saying your trying to link a 32 bit .o using a 64 bit linker, the mingw32 would agree

[jessfraz]

well its weird because the x86_64-w64 in the prefix is supposed to mean 64bit, its poorly named trying to find link to what I read when I originally wrote the binary compile script

[jessfraz]

so from what I can tell for 32bit i686-w64-mingw32-gcc is used and for 64bit x86_64-w64-mingw32-gcc is used.

[mwhudson]

Still, /tmp/go-link-623415307/000000.o, which I think is a file produced by cgo, seems to be 32 bit when it needs to be 64-bit. Can you run go build -x and stick the output in a gist?

[jessfraz]

will do! also this is the docs for mingw http://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/#building-binutils-cross-toolchain

[jessfraz]

https://gist.github.com/anonymous/b6c4010d380d4a80f0f8

[jessfraz]

FWIW this is the output with go 1.4.3 https://gist.github.com/anonymous/5c991873a89319fc958f

[mwhudson]

Hm, well one thing that's iirc changed is that there is external linking support for windows now. Can you try adding -v to -ldflags? And maybe -linkmode=internal too?

[davecheney]

Hm, well one thing that's iirc changed is that there is external linking support for windows now. Can you try adding -v to -ldflags? And maybe -linkmode=internal too?

That would explain it. The previous 1.4 behaviour is "schmeh, i'll ignore your suggestion for linking and do it myself".

[jessfraz]

yay that works omg thanks for the speedy help \o/

[mwhudson]

This still looks like a bug in something or other, fwiw: external linking should work when cross compiling.

[davecheney]

@jfrazelle could you run file /tmp/go-link-623415307/000000.o or similar (not the microsoft tools) to solve the argument about which arch this binary is? There might be something bone headed in the go tool that is passing -m32 or something when it should not.