From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Christian Stewart <christian@aperture.us>
Cc: Anisse Astier <anisse@astier.eu>,
Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v8 1/1] package/go: use host compiler when go-bootstrap unsupported
Date: Tue, 20 Aug 2024 00:31:55 +0200 [thread overview]
Message-ID: <ZsPH2xAvcIc7oBUA@landeda> (raw)
In-Reply-To: <CA+h8R2q9ueiNE+SKXNJGq4zGnquRZ=jN-8MHKOwUNVNcBj7yXA@mail.gmail.com>
Christian, All,
On 2024-08-19 14:34 -0700, Christian Stewart spake thusly:
> On Mon, Aug 19, 2024 at 2:17 PM Yann E. MORIN <yann.morin.1998@free.fr> wrote:
> > > Recent changes added go-src with the intent of adding go-bin later. This
> > > commit changes go-src to depend on the host Go compiler to bootstrap
> > > go-src on architectures that cannot build go-bootstrap-stage1 (such as arm64).
> > >
> > > Signed-off-by: Christian Stewart <christian@aperture.us>
> >
> > Thanks for this new iteration. But I'd rather first have the support for
> > host-go-bin, rather than rely on the system go.
> >
> > Indeed, usng host-go-bin would not require the user to install go on
> > their system; host-go-bin can be used on oder distributions where a go
> > compiler is not available, or where the go compiler is too old to build
> > go-src.
> >
> > So, I am not convinced about this "use the system go" solution.
>
> These are two different use cases.
>
> What you are describing is downloading and using the pre-built Go for
> everything.
>
> What this patch accomplishes is bootstrapping host-go-src using the
> system Go compiler.
>
> Both can be supported, this patch fixes when we select host-go-src on
> an arm64 machine.
Sorry, I was not clear enough, my bad.
So, to make it clear and explicit, here is what I think we should
support:
- full bootstrap chain up to host-go-src, at least where possible
- last-stage bootstrap with host-go-bootstrap-stage3-bin and host-go-src
- host-go-bin
As far as I can see, there are binary releases for all meaningful
architectures:
https://go.dev/dl/
* go 1.19.13 (our stage-2 bootstrap) has:
- go1.19.13.linux-386.tar.gz
- go1.19.13.linux-amd64.tar.gz
- go1.19.13.linux-arm64.tar.gz
- go1.19.13.linux-armv6l.tar.gz
- go1.19.13.linux-ppc64le.tar.gz
- go1.19.13.linux-s390x.tar.gz
* go 1.21.8 (our stage-3 bootstrap) has:
- go1.21.8.linux-386.tar.gz
- go1.21.8.linux-amd64.tar.gz
- go1.21.8.linux-arm64.tar.gz
- go1.21.8.linux-armv6l.tar.gz
- go1.21.8.linux-loong64.tar.gz
- go1.21.8.linux-mips.tar.gz
- go1.21.8.linux-mips64.tar.gz
- go1.21.8.linux-mips64le.tar.gz
- go1.21.8.linux-mipsle.tar.gz
- go1.21.8.linux-ppc64.tar.gz
- go1.21.8.linux-ppc64le.tar.gz
- go1.21.8.linux-riscv64.tar.gz
- go1.21.8.linux-s390x.tar.gz
So if we introduce host-go-bootstrap-stage3-bin with go 1.21.8, we
basically get support for all architectures (and more) where we
expect Buildroot to run (to run, not to generate code for!). Maybe one
could argue that riscv32 is missing, but I doubt anyone has a riscv32
machine powerful enough to run Buildroot on (riscv64 sure, riscv32 much
less), so that is not a concern either (IMHO).
This would also fix the issue you are reporting of running Buildroot on
an AArch64 (aka arm64) machine.
> This is no different from using the host gcc to bootstrap the
> Buildroot gcc, no?
As I explained previously, the suggestion above would allow having a
"final" go compiler everywhere, even for those distributions where
there is none, or where it is too old, for which your proposal does not
work.
Currently, the oldest gcc supported to build gcc 14.x, is gcc 4.8.3 [0]
released 2014-05-22, just ten years ago, so virtually all distributions
that make sense today have such a gcc or more recent, so the bootstrap
case is not really an issue, and a C compiler really is a basic tool we
can expect everywhere, while a go compiler is definitely not a basic
tool we can expect or rely on.
[0] https://gcc.gnu.org/install/prerequisites.html
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2024-08-19 22:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 20:33 [Buildroot] [PATCH v8 1/1] package/go: use host compiler when go-bootstrap unsupported Christian Stewart via buildroot
2024-08-19 21:17 ` Yann E. MORIN
2024-08-19 21:34 ` Christian Stewart via buildroot
2024-08-19 22:31 ` Yann E. MORIN [this message]
2024-09-15 9:15 ` Arnout Vandecappelle via buildroot
2024-09-15 14:17 ` 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=ZsPH2xAvcIc7oBUA@landeda \
--to=yann.morin.1998@free.fr \
--cc=anisse@astier.eu \
--cc=buildroot@buildroot.org \
--cc=christian@aperture.us \
--cc=thomas.petazzoni@bootlin.com \
/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