proposal: go build: natively support fat-binaries

[skyzyx]

The core of this proposal is to bring support for fat-binaries to go build.

• Apple has done this during every CPU architecture transition they've made (like the one we're currently in), so there is certainly precedent in terms of use-case. Docker has also added support for multi-arch images, which work conceptually-similarly (multiple CPU builds with a single entrypoint).

• GoReleaser has added support for macOS Universal Binaries. While this is a handy shortcut for macOS users, I know that teams have dabbled with it in Linux as well. With C it was "too hard", but with Go (and I'm avoiding talking about CGO), perhaps it could be easier?

• GoReleaser’s implementation results in essentially a double-sized binary. If this is the best job that can be done, then so be it (this is outside the realm of my personal expertise). But it seems like there may be an opportunity to optimize the CPU-specific bits for each architecture from the CPU-agnostic bits (which, again, this is outside the realm of my personal expertise) which could result in a less-than-double-sized binary.

• Proposed end-user syntax could be something like:

  GOOS=darwin GOARCH=amd64,arm64 go build ...

[randall77]

There's no easy way to avoid the 2x blowup. The internal format of a fat binary is literally two independent binaries glued together. There is no provision for shared pieces.

You can use lipo or a simple tool I wrote to make them yourself.

It's not clear to me that we want to go down this route. There are lots of os/arch-specific things the go tool could do for you besides fattening, like signing, merging into a docker file, etc. We have to draw the line somewhere. I'm happy to leave a thing-that-is-only-needed-for-a-few-years-for-transition on the other side of the line.

[skyzyx]

Sure. Well I thought it was worth asking.