I’ve upgraded the builders to Go 1.5.2. The table below shows what gets built with what. The “standard xxx build” refers to the binary Go package from golang.org/dl, these builds are at least somewhat dynamically linked and require SSE instructions. The “cross compiled” ones are static and may use 387 only instructions for the 386 builds (I’m not 100% sure).
Thanks for the info. Do the builds require write access to the Go install dir? After upgrading my builder to Go 1.5.1 (working on 1.5.2 now), I get this error when building:
go install runtime: mkdir /usr/local/go/pkg/darwin_amd64/: permission denied
Go was installed using the standard package mechanism and the build is running as a non-root user, so the build doesn’t have access to write to the Go install dir.
If you’re cross compiling, the Go compiler will compile the standard library for the other architectures and expect to be able to store them in the global pkg dir (the one in your error message). I’ve also seen cases where it wants to recompile for example “runtime” due to timestamp issues in the Go tree. In either case, this is really a matter of the Go compiler itself, not our build process as such.
What did you do the first time, and what OS are you actually on? “go build” generally doesn’t actually save the intermediate object files, so it may have rebuilt runtime but into a temp dir and then thrown it away. It can also be a matter of building with or without cgo or race detector, as those kind of low level options require rebuilding runtime and other stdlib packages for the new options.
You’re cross compiling. See the first sentence of my first reply. As for why that doesn’t happen with go build, that’s down to the difference between go build and go install (or go build -i).
Ok, I do see the same behavior with go build -i. Thanks for the help. Any ideas on work arounds? Or should I just go build -i hello.go for each target as root?
On my build setups, the build user actually owns the compiler installation, for this reason among others. You could restrict that to just the pkg dir, of course. There’s also a -pkgdir option you can give the compiler to store all pkgs somewhere other than the default, but our build script doesn’t do that so you’d need to patch it in that case… You could also patch it to not use build -i, but then you’re effectively rebuilding the entire stdlib for every OS on every build and that gets boring to wait for quite quickly…
It would be neat if pkgdir could be set by an environment variable, I guess… You may be able to hack something together by setting GOROOT, but you’re more likely to just bork your compiler setup instead in the process.
Thanks. I tested making the pkg dir read/write and letting it install everything, and that works. But changing the permissions on the pkg dir breaks things, which is surprising. It seems it’s deleting and re-creating the compile tool each time. Anyway, thanks for the info.
As for why that doesn’t happen with go build, that’s down to the difference between go build and go install (or go build -i).
