[Buildroot] [PATCH v1 1/1] package/go: use host compiler when go-bootstrap unsupported

Thomas Petazzoni thomas.petazzoni at bootlin.com
Wed Jul 21 20:49:13 UTC 2021


Hello Christian,

On Mon, 21 Jun 2021 19:43:37 -0700
Christian Stewart <christian at paral.in> wrote:

> All Go compiler versions > 1.4.x (old) are written in Go, and require a existing
> compiled Go version to use to build from source.
> 
> https://golang.org/doc/install/source#bootstrapFromSource
> 
> The process for "bootstrapping" the Go compiler in Buildroot is:
> 
> 1. Compile a C/C++ cross-compiler (gcc) as the host toolchain.
> 2. Build go-bootstrap (which is Go 1.4.x and written in C)
> 3. Build go 1.16.x (written in Go) using go-bootstrap.
> 
> The problem is that step 2 - build go-bootstrap - does not work on 64-bit arm.
> The Go compiler from 1.4.x is compatible with x86, x86_64, and arm (32 bit).

So perhaps my brain is not smart enough here, but how is the Go
compiler then build on 64-bit ARM ?

> Signed-off-by: Christian Stewart <christian at paral.in>
> ---
>  package/go-bootstrap/go-bootstrap.mk | 6 ++++++
>  package/go/Config.in.host            | 2 --
>  package/go/go.mk                     | 4 ++++
>  3 files changed, 10 insertions(+), 2 deletions(-)

Implementation-wise, I agree with the feedback from Baruch, we need
some checks in support/dependencies/.

Normally, the way we do things is that packages express their
dependency on a particular system tool by selecting a hidden boolean.
For example packages that need java on the host will select
BR2_NEEDS_HOST_JAVA, and in support/dependencies/dependencies.sh, if
BR2_NEEDS_HOST_JAVA=y, we check if java is installed.

The other model that we have is for optional host tools, where we can
use the system-provided one or fallback to building our own if not.
That's for example what support/dependencies/check-host-lzip.{mk,sh} is
doing.

check-host-lzip.mk calls suitable-host-package, which itself calls the
check-host-lzip.sh script to verify if lzip is installed. If there is
no suitable lzip available on the host, then check-host-lzip.mk defines
BR2_LZIP_HOST_DEPENDENCY to host-lzip, so that packages who need the
lzip utility can depend on $(BR2_LZIP_HOST_DEPENDENCY). It will be
empty if the system has a lzip program, or it will be set to host-lzip
if Buildroot needs to build its own.

Another feature for the lzip situation is that we can force Buildroot
to build the host packages even if the tool is found on the machine,
using BR2_FORCE_HOST_BUILD=y.

The thing is that your host-go-bootstrap situation does not exactly fit
these situations.

I think the easiest would be to do like we do for Java, but only select
BR2_NEEDS_HOST_GO if we're on a host architecture that doesn't support
building host-go-bootstrap.

If we go this route, then it should look like this:

 * Top-level Config.in defines BR2_NEEDS_HOST_GO as an hidden boolean

 * support/dependencies/dependencies.sh should test if a functional Go
   compiler is available on the machine if BR2_NEEDS_HOST_GO is
   defined, and if not bail out with a hard error

 * BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS and
   BR2_PACKAGE_HOST_GO_HOST_ARCH_SUPPORTS should loose their "depends
   on BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS" and instead have
   something like:

	select BR2_NEEDS_HOST_GO if !BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS

 * go.mk should be modified to not use host-go-bootstrap if
   !BR2_PACKAGE_HOST_GO_BOOTSTRAP_ARCH_SUPPORTS. I don't think
   host-go-bootstrap should be modified like you did however, the
   changes should be contained into package/go/go.mk.

The one thing that bothers me however is the hardcoding of /usr/lib/go
in your proposal as the location of the Go compiler. I guess we could
have some logic in the top-level Makefile that looks for the path of
the host Go compiler perhaps ?

Does this make sense ?

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


More information about the buildroot mailing list