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

[Fiona Klute via buildroot <buildroot@buildroot.org>]

Yann, everyone,

I've just sent a new patch that sets -fuse-ld=bfd for package/containerd:
https://patchwork.ozlabs.org/project/buildroot/patch/20250204143227.1233163-1-fiona.klute@gmx.de/

It works for me (host-go-src, musl), I'd appreciate tests with other
toolchains.

Best regards,
Fiona

Am 04.02.25 um 13:13 schrieb 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.
>

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot