cmd/go: allow to install cross-compiled binaries when GOBIN is set

[hyangah]

$ GOBIN=/tmp/release GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go1.20rc1 install golang.org/dl/go1.19.4@latest
go: cannot install cross-compiled binaries when GOBIN is set

What version of Go are you using (go version)?

$ go version
go version go1.19.4 darwin/amd64

What did you do?

Want to build a go tool for a different platform, but want the compiled binary to be in a directory different from my default installation directory.

What did you expect to see?

Successfully cross-compile the binary and have the result somewhere under GOBIN.

What did you see instead?

Error.

I believe the rejection of cross-compiled binary when GOBIN is set has a long history, that predates both Go modules and the recent major change in the meaning of go install <main_package_path>@<version> repurposed for clean tool installation. There were multiple related discussion topics (#13063 #14295 #9769) but all were closed as "FrozenDueToAge".

An alternative is to support -o flag for go install or go build <main_package>@<version> which is under discussion in a different context. #44469.

[dmitshur]

CC @bcmills, @matloob.

[bcmills]

We had some confusion around the semantics of GOBIN circa Go 1.13 that resulted in a bit of a shift, which seems to have stuck.

I agree that, given the current semantics (and especially given the current interop stories around CPU migrations on various vendors), it seems fine to allow go install to install cross-compiled binaries to GOBIN.

[kylelemons]

We're also running into this. We're working on tooling to improve the development cycle time for Kubernetes microservices, and the binaries run in Linux in the cluster but most developers are building on M1. Being able to GOBIN=path GOOS=linux GOARCH=amd64 go install ./... makes the tooling able to be a lot simpler.

Any chance this could be reviewed by the proposal review committee?

[gopherbot]

Change https://go.dev/cl/568396 mentions this issue: cmd/go/internal/work: allows installing cross-compiled binaries GOBIN is set

[rsc]

I think the GOBIN behavior is correct, because otherwise we risk smashing people's local binaries accidentally when GOBIN=$HOME/bin. But I think adding a -o flag to go install makes a lot of sense.

[seankhliao]

Wouldn't doing #44469 go build -o out pkg@ver make more sense?

[rsc]

Perhaps. One or the other.

[matloob]

I think it would be a good idea to do either go build -o or go install -o. Based on the discussion on that issues in seems like the go build -o option might have more obvious behavior (especially since we already support go run package@version?