Looks like my attempt to fix #9769 is overzealous. Taking a look.

I suspect the way you are trying to use go install should fail, it's just a slightly confusing error message. When you go install mycmd, it typically installs in $GOPATH/bin, or if it's set, $GOBIN. When cross compiling, there is really no good place to do the installation. Both of those bin directories are designed to be on your $PATH, so creating subdirectories does not make sense.

In general with your own programs, you should go build cross-compiled binaries, not go install them. You can use -o to specify where you want the binary to end up.

However cross-compile go installs of cmd/* binaries should work, except cmd/go when GOBIN is set. It looks like that's one case I missed, so I'm looking at it and improving the error message.

Makes sense. I changed my rules from:

go install -x
GOARCH=386 go install -x

to

go install -x
GOARCH=386 go build -x -o $(GOBIN)/linux_386/binary

and it's now working as before.

Though, to be honest, I liked the previous way better, less typing, more streamlined rules for building. 386 binaries are executable on the amd64 platform, so makes sense to have them in the subdirectory of $GOPATH/bin.

If this change in policy is final, certainly the error message should be improved to tell that go install won't work for cross-compiling and that go build -o should be used.

Oh, few minutes later I see another bad consequence of this change in policy. go build is not the same as go install, now if I run it again it's again rebuilding from the scratch, even if there were no changes in the source code and the binary is up-to-date. go install is clever not to rebuild if not needed.

Now, seeing this behaviour, I don't like this policy change at all. There should be a way to go install even for cross-compiling, IMHO.

You should probably take up the issue of whether or not it is a good idea on #9769. I tend to think of cross compilation as a special case, but I see your point.

CL https://golang.org/cl/12384 mentions this issue.

I left a note on #9769, too. Although, I'm still a bit puzzled, #9769 specifically mentions creating subdirectories under $GOBIN as problematic, where I see behaviour change even without $GOBIN set.

I'd just like to point out how problematic this issue is: When cross-compiling an executable, all dependencies are cross-compiled as well. This means that without functional cross compilation support for go install, all dependencies are rebuilt every time the end user's executable is built, which takes a lot of time.

I hit the same error and wonder what needs to be done to avoid rebuilding all the standard library dependencies on every invocation of GOOS=linux go build (when cross-compiling on a Mac).

The go build command has a -i flag that can be used when cross compiling.

@crawshaw Cool, that helps! It saves a lot of time when compiling. But of course it would still be great if with the release of Go 1.5 the build system will enable avoiding any gratuitous compilation when cross-compiling, even if it's just the end user's binary.

Came across this issue when trying beta2 out. Would also prefer the old behavior.

Error message text, so that it is possible to find this issue by exact text:

go install: cannot install cross-compiled binaries when GOBIN is set

This change completely breaks my cross-compilation workflow and is very frustrating. (GOBIN is not set)

CL https://golang.org/cl/12938 mentions this issue.

FWIW, you should be able to say GOARCH=xxx go install -buildmode=archive prefix/... to only compile and install the non-main packages.