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).
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.
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.