If I set back GOOS to darwin with export GOOS=darwin command, then it works again, it uses the GOPATH variable as deployment destination, again.

I'm seeing this same issue but with exporting GOOS=windows on Linux and running go get, which in turn calls go install. I have GOPATH set to a local directory but go install appears to be ignoring it. My workaround is to just run go get before changing GOOS in my build scripts.

Probably obvious but my CI job is building Windows and Linux binaries on a Linux build machine.

@matthewcummings can you please open a new issue including all the required information in the template. Please also include the output of adding the -x flag to go get/install which will show us the commands the Go tool executed.

If this turns out to be a duplicate then we’ll merge the issues. Thanks.

@gszecsenyi - Please use go build instead of go install when cross-compiling. The reasons are clearly laid out in Dave's blog post. I suggest closing this issue.

Using go build vs go install
When cross compiling, you should use go build, not go install. This is the one of the few cases where go build is preferable to go install.

The reason for this is go install always caches compiled packages, .a files, into the pkg/ directory that matches the root of the source code.

For example, if you are building $GOPATH/src/github.com/lib/pq, then the compiled package will be installed into $GOPATH/pkg/$GOOS_$GOARCH/github.com/lib/pq.a.

This logic also holds true for the standard library, which lives in /usr/local/go/src, so will be compiled to /usr/local/go/pkg/$GOOS_$GOARCH. This is a problem, because when cross compiling the go tool needs to rebuild the standard library for your target, but the binary distribution expects that /usr/local/go is not writeable.

Using go build rather that go install is the solution here, because go build builds, then throws away most of the result (rather than caching it for later), leaving you with the final binary in the current directory, which is most likely writeable by you.

Closing for now given this (very good) explanation from @davecheney’s post.