Builders upgraded to Go 1.5.2

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

OS-Arch Go Build
darwin-amd64 Native, standard darwin-amd64 build
dragonfly-amd64 Cross compiled from linux-amd64
freebsd-amd64 Cross compiled from linux-amd64
freebsd-386 Cross compiled from linux-amd64
linux-amd64 Native, standard linux-amd64 build
linux-386 Cross compiled from linux-amd64
linux-arm Cross compiled from linux-amd64
netbsd-amd64 Cross compiled from linux-amd64
netbsd-386 Cross compiled from linux-amd64
openbsd-amd64 Cross compiled from linux-amd64
openbsd-386 Cross compiled from linux-amd64
solaris-amd64 Cross compiled from linux-amd64
windows-amd64 Native, standard windows-amd64 build
windows-386 Native, standard windows-386 build

(We also build successfully with Go 1.3 and 1.4, as verified by

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.

Ok, but how come I can do this:

env GOOS=darwin GOARCH=amd64 go build hello.go

without a similar error? Is it just because hello.go doesn’t use the standard library?

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.

All I did the first time was clone the repo and run all. I’m on FreeBSD. The full log is here:

You’re cross compiling. See the first sentence of my first reply. :wink: 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? :wink:

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. :smiley:

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.