Does GOARCH=amd64 go build
build the same binary when using a 32-bit port of the Go compiler, at least for pure Go programs?
评论:
rmn87:
jeffrallen:Yep.
THEHIPP0:Here is the same binary built two ways. The host machine is amd64 in this case, but it wouldn't matter, you'd see the same thing if the host machine was 386:
$ GOARCH=amd64 go build -o amd64 $ GOARCH=386 go build -o 386 $ ls -l 386 amd64 -rwxrwxr-x 1 jra jra 2281296 Mar 20 08:39 386 -rwxrwxr-x 1 jra jra 2814120 Mar 20 08:39 amd64 $ file 386 amd64 386: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, not stripped amd64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
They are not "the same binary", because they are the 2 different binaries for the 2 different architectures that you are asking about. However, they are semantically the same binary, in that they are built from the same code, and are expected to implement the same semantics, even if the byte stream of instructions to the CPU differs. If they show different semantic behavior, that's a defect you can file an issue on.
-jeff
BTW: Remember that you can run "GOARCH=xxx go install" in your $GOROOT/src directory in order to speed up future builds. Otherwise, your cross-arch builds will always build the entire standard library from scratch. Same is true for cross-OS builds (i.e. using a Linux host to make Windows binaries.)
ChristophBerger:BTW: Remember that you can run "GOARCH=xxx go install" in your $GOROOT/src directory in order to speed up future builds. Otherwise, your cross-arch builds will always build the entire standard library from scratch. Same is true for cross-OS builds (i.e. using a Linux host to make Windows binaries.)
Or you build with
go build -i
which will cache all compiled packages until they change.
4ad:I haven't tried this myself, but unless there is an open issue preventing this, it should be possible. The Go documentation does not mention restrictions on the combination of GOOS and GOARCH values.
Yes, the toolchain is always a cross compiler. For pure Go packages it doesn't matter what your build system is. Only the target.
