Re: [Buildroot] [PATCH 1/1] package/containerd: fix build with toolchain without Gold linker

[yann.morin@orange.com]

Arnout, Fiona, Christian, All,

On 2025-02-05 09:03 +0100, Arnout Vandecappelle spake thusly:
> On 04/02/2025 22:23, Christian Stewart wrote:
> > On Tue, Feb 4, 2025, 6:32 AM Fiona Klute <fiona.klute@gmx.de
> > <mailto:fiona.klute@gmx.de>> wrote:
[--SNIP--]
> >     +ifeq ($(BR2_aarch64),y)
> >     +# Go forces use of the Gold linker on aarch64 due to a bug in BFD that
> >     +# is fixed in Binutils >= 2.41 (so all versions provided by
> >     +# Buildroot). Forcing Gold will break with toolchains that don't
> >     +# provide it, so override the flag and use BFD.
> >     +# See: https://github.com/golang/go/issues/22040 <https://github.com/
> >     golang/go/issues/22040>
> >     +CONTAINERD_EXTLDFLAGS += -fuse-ld=bfd
> >     +ifeq ($(BR2_TOOLCHAIN_USES_MUSL),y)
> >     +# Go exe build with PIE doesn't work with musl.
> >     +# See: https://github.com/golang/go/issues/17847 <https://github.com/
> >     golang/go/issues/17847>
> >     +CONTAINERD_EXTLDFLAGS += -Wl,--no-pie
> >     +endif
> >     +endif
[--SNIP--]
> > This looks good to me. But shouldn't we apply this more generally to
> > go-src and go-bin? It's true for all Go packages that we should pass
> > these flags right? Why specifically containerd?
[--SNIP--]
>  Yes I agree - this patch (and Yann's infrastructure patch that this patch
> depends on) should be in pkg-golang instead of an individual package.

Not sure I entirely grok that. The change I submitted is in pkg-golang,
as it is infra.

So, I guess you only actually suggested moving setting -fuse-ld=bfd and
-Wl,--no-pie flags into pkg-golang, right?

When I initially needed -fuse-ld=bfd for filebeat, I did not feel very
confident that we should do it unconditionally. Indeed, none of the
{host-,}golang-package packages we had at that time needed it at all. So
I concluded that filebeat was special (it was already special in a few
other respects, so meh).

And since I am far from a go expert, I have no idea how impactful such a
change would be. So I was a bit skeptical at making it part of the infra
so that it applied to all packages.

Still today, only one package (containerd) actually needs it; it is
still an exception. Thus _I_ am still a little bit skeptical that this
should be moved into the infra.

But if Christian, our eresident go expert, says we should go for it,
then let's do it.

Still, I believe there should be a way for packages to be able to pass
arbitrary extldflags, and thus the variable should be exposed.

Regards,
Yann E. MORIN.

-- 
                                        ____________
.-----------------.--------------------:       _    :------------------.
|  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