Re: [Buildroot] [PATCH 1/1] package/go/go-src: stop forcing binutils-gold dependency on aarch64

[yann.morin@orange.com]

Fiona, All,

On 2025-02-04 12:37 +0100, Fiona Klute spake thusly:
> According to the discussion in the Go issue, there was another bug that
> got fixed with 2.41.
> https://github.com/golang/go/issues/22040#issuecomment-1430110400

Yes, that's exactly why I needed to pass -fuse-ld=bfd for filebeat but
not for arm.

> Am 04.02.25 um 12:13 schrieb yann.morin@orange.com:
[--SNIP--]
> > So, packages that need to specify "-fuse-ld=bfd" would do so
> > unconditionaly, just maybe for the AArch64 case, which is the only one I
> > know can cause the build failure (not all packages have the issue, as
> > can be explamplified by the fact that we have no such failures in the
> > autobuilders).
> I like that approach, but as mentioned above the toolchains will have to
> be a bit more recent.

2.36 worked for me, at least. But unless the toolchains have to be less
than a year old, I think it is OK to require that.

But now, as you mentioned [0], if gold gets dropped, then I'd expect
newer binutils to no longer install ld.bfd either (because there'd be
only only linker left). So we'd be back to the case of old toolchains,
where gold did not yet exist, and thus ld.bfd did not exist either.

So, if we need to be future proof, then we need to design a solution
that works in all cases;
  - old toolchains where gold did not exist, and where ld.bfd did not
    exist, o it's just 'ld;';
   - toolchains where binutils was /configure-d with --disable-gold,
    so it's just 'ld';
  - toolchains where gold exists, and has both ld.bfd and ld.gold, and
    where we want to use 'ld.bfd';
  - future toolchains where gold no longer exists, so it's again just
    'ld'.

[0] https://github.com/golang/go/issues/22040#issuecomment-2630848777

> What's odd is that my test build failed. As you can see, with your patch
> setting CONTAINERD_EXTLDFLAGS += -fuse-ld=bfd works to use ld.bfd, but
> confusingly there's an error that didn't appear when patching Go:
[--SNIP--]
> /home/fiona/development/buildroot/output/revpi/host/lib/gcc/aarch64-buildroot-linux-musl/13.3.0/../../../../aarch64-buildroot-linux-musl/bin/ld.bfd:
> read-only segment has dynamic relocations
> collect2: Fehler: ld gab 1 als Ende-Status zurück
> 
> Any ideas? Is the different order of arguments messing things up?

Ordering of args should not matter: the latter should win.

Maybe you can requier verbose output:

    FOO_EXTLDFLAGS = -fuse-ld=bfd -Wl,--verbose -v

Otherwise, no idea, as I am not a go guy... I just had to fiddle with
filebeat a few years back, managed to get it fall in place with the
referenced change, but other than that, I am just a monkey typing on a
keyboard in this go land. ;-)

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