Closed dberliner closed 5 years ago
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 ...
):
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:
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
.GOOS
and GOARCH
when building a package for the target (in package/pkg-golang.mk
).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
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:
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.
Nice!! That does seem to confirm it.
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.
Fixed by #54
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.