Re: [Buildroot] [PATCH 1/1] package/go: make pre-built compiler provide target support too

[yann.morin@orange.com]

Florian, All,

On 2025-07-07 17:43 +0200, Florian Larysch spake thusly:
> On Sun, Jul 06, 2025 at 09:59:53PM +0200, Romain Naour wrote:
> > I believe there is an misunderstanding here.
> Yeah and I'm afraid you've lost me completely now, sorry. :(

To be honest, I also got slightly lost. I agree with Romain that the
original commit message was not entirely clear (I had to read it very
carefully to get it, but then I'm still waiting for my cafeine shot to
kick in...)

But also I'm not sure I entirely groked Romain's comments either. ;-p

So, I've had a go (aha!) at rewriting a commit log as I understood the
situation, building upon your initial commit log and trying to account
for Romain's comments:

---8<---
All go packages must depend on BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS,
which ensures that we do have a go compiler available for that target.

Now, BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is restricted to the
availability of a host go bootstrap, i.e. that the build machine can
bootstrap a go compiler.

However, there are architectures which can not bootstrap a go compiler,
but for which exist pre-built go toolchains; this is the case, for
example, of AArch64.

Thus, currently, on an AArch64 host, we can't build go packages (for
target or host), because we can't bootstrap a go compiler.

It is to be noted that a single go compiler can generate code for all
the architectures supported by go. When host-go-bin was added in commit
7b2a164b7460 (package/go/go-bin: new host-go provider), the host
depenency was properly accounted for: it is already possible to build
host-go packages with go-bin. However, the fact that a go compiler, in
addition to its native target, can also generate code for all supported
architectures, was missed at the time.

We fix that by relaxing the condition under which
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is set, by allowing go-bin
along go-bootstrap. This allows a situation where the host can't
bootstrap, but for which there is a pre-built toolchain, to build go
packages for a supported target.
---8<---

I hope that is clearer and fits the bill. If I missed anything, don;t
hesitate to amend/fix/ditch that proposal.

Regards,
Yann E. MORIN.

> > When you say "we can fall back on the pre-built toolchain", we indeed fall back
> > on the pre-built go cross-toolchain (host-go) but since
> > BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS is missing, host-go can't be used to
> > build go target packages (even if it's installed in HOST_DIR).
> > 
> > Since it's a pre-built toolchain there is no native build involved.
> > As you explained, the full bootstrap via BR2_PACKAGE_HOST_GO_SRC is not
> > supported on aarch64 hosts.
> > 
> > With your patch applied, we can now use host-go (provided by host-go-bin) on
> > aaarch64 hosts to build go target packages. I'm agree with your changes, it's
> > just the commit log that needs to be reworded (with the link to the commit
> > adding host-go-bin package).
> 
> As I read it, this is more or less what the commit message is already
> saying. Can you please explain where you think it is incorrect or
> imprecise?
> 
> The only reference to a native build in the commit message is when it is
> describing the current broken state that causes a native build of target
> packages to happen erroneously.
> 
> I can of course add the link.
> 
> Florian

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  Yann E. MORIN  | Real-Time Embedded |    __/ )   | /"\ ASCII RIBBON |
|                 | Software  Designer |  _/ - /'   | \ / CAMPAIGN     |
| +33 638.411.245 '--------------------: (_    `--, |  X  AGAINST      |
| yann.morin (at) orange.com           |_="    ,--' | / \ HTML MAIL    |
'--------------------------------------:______/_____:------------------'

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot