Seperate Go support conditionals

[dberliner]

Referencing the changes in https://patchwork.ozlabs.org/patch/962489/

Currently Go support uses a single variable to deice host and target support. We need to separate the functionality to provide individual variables for both cases.

• [x] Change BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS to only determine host support
• [x] Create BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS to decide target support (conditions provided in above link)
• [x] Add support for Go installation targeting host&target or just host.

[drbild]

Here’s what I think is happening, based on the two documents I’ll link below.

When building the Go toolchain (i.e., running main.bash):

• GOHOSTOS and GOHOSTARCH specify which os/arch to build the go compiler (go) for. For buildroot this will always be the native arch, but could be different if we wanted to build the go toolchain to itself run on the target platform (this would be cross-compiling the compiler).
• GOOS, GOARCH specify the default os/arch to pre-build the Go standard libraries for (in addition to the host arch). I'm not sure if this pre-building actually happens. Regardless, it is not necessary to specify GOOS, and GOARCH here --- just a potential optimization.

When building a program using that toolchain (i.e., running go build ...):

• By default will build for the host arch.
• GOOS, GOARCH can be overridden to build for a different target. If not pre-built with the toolchain, the Go standard library will be built for this new arch specifically for this project. This compiled standard lib is not shared between projects.

So for buildroot, this means:

• specify the target GOOS, GOARCH when building the toolchain (in package/go/go.mk), just to get the standard lib prebuilt for the target. Multiple packages won’t have to each compile the standard lib themselves. (if the prebuild happens the way I think.) This is already in upstream master.
• specify the target GOOS and GOARCH when building a package for the target (in package/pkg-golang.mk).
• do not specify GOOS and GOARCH when building a package for the host (in package/pkg-golang.mk). It will default to the host arch.

The latter two are what Mirza’s patch does (https://patchwork.ozlabs.org/patch/962489/), which definitely works.

So the only cleanup that should be necessary is

• Thomas’s “depends on” split, which you’ve already added
• Fixing package/go/go.mk to support host builds on a buildroot target arch that Go doesn’t support. Just not setting GOOS and GOARCH is probably sufficient (like how GOARM is only set if the target arch is arm.)

Sources:

• https://medium.com/@rakyll/go-1-5-cross-compilation-488092ba44ec
• https://golang.org/doc/install/source

[dberliner]

This looks about right. When I remove the GOARCH variable the output is

Building packages and commands for linux/amd64.
---
Installed Go for linux/amd64 in /home/vagrant/xaptum-buildroot/tpmbuild/gotest2/build/host-go-1.10.2
Installed commands in /home/vagrant/xaptum-buildroot/tpmbuild/gotest2/build/host-go-1.10.2/bin

With the variables in

Building packages and commands for host, linux/amd64.
Building packages and commands for target, linux/arm.
---
Installed Go for linux/arm in /home/vagrant/xaptum-buildroot/tpmbuild/gotest2/build/host-go-1.10.2
Installed commands in /home/vagrant/xaptum-buildroot/tpmbuild/gotest2/build/host-go-1.10.2/bin

Knowing this I should be able to move forward tomorrow.

[drbild]

Nice!! That does seem to confirm it.

[dberliner]

Something didn't quite sit right so I kept digging and I figured out why that guy on stackoverflow kept insisting those variables were for the toolchain target. Go is written in Go so it needs to bootstrap and has 3 stages. If we are going to get a compiler for a foreign architecture we need to have one in the host first, the executable I was looking at (bin/go) was an intermediate step for bin/linux_arm/go which looks like a go compiler for the target architecture.

[drbild]

Fixed by #54