Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: Christian Stewart <christian@paral.in>
Cc: "Yann E . MORIN" <yann.morin.1998@free.fr>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v1 1/1] package/go: use host compiler when go-bootstrap unsupported
Date: Wed, 21 Jul 2021 22:49:13 +0200	[thread overview]
Message-ID: <20210721224913.3d600ccc@windsurf> (raw)
In-Reply-To: <20210622024337.3009417-1-christian@paral.in>

Hello Christian,

On Mon, 21 Jun 2021 19:43:37 -0700
Christian Stewart <christian@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@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
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

  parent reply	other threads:[~2021-07-21 20:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22  2:43 [Buildroot] [PATCH v1 1/1] package/go: use host compiler when go-bootstrap unsupported Christian Stewart
2021-06-22  3:10 ` Baruch Siach
2021-06-28 18:00   ` Christian Stewart
2021-07-21 20:49 ` Thomas Petazzoni [this message]
2021-07-24 20:50   ` Christian Stewart
2022-07-24 22:55   ` Christian Stewart via buildroot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210721224913.3d600ccc@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@buildroot.org \
    --cc=christian@paral.in \
    --cc=yann.morin.1998@free.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox