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

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

Am 04.02.25 um 12:13 schrieb yann.morin@orange.com:
> Fiona, All,
>
> On 2025-02-04 11:52 +0100, Fiona Klute spake thusly:
>> Am 04.02.25 um 07:26 schrieb yann.morin@orange.com:
>>>> Go forces the GOLD linker when dynamically linking Go code, because
>>>> old versions of BFD caused errors. The issue has been fixed in
>>>> Binutils since at least 2.41 according to the upstream description of
>>>> the patch added with this commit [1], and now forcing GOLD causes
>>>> linking failure if ld.gold is not available. The associated Golang
>>>> issue [2] is still open.
>>> I have send a patch back a while ago, that allowed to at least work
>>> around the issue for affected packages:
>>> https://patchwork.ozlabs.org/project/buildroot/patch/876f3a7bb6a2375193fc8f06ab856d2449f83727.1699547993.git.yann.morin@orange.com/
> [--SNIP--]
>> One question though: Is there an existing way to check the Binutils
>> version of an external toolchain? For people with Binutils < 2.41 with
>> ld.gold forcing BFD might actually break things, so ideally I'd want to
>> make the flag conditional on Binutils >= 2.41 (all Buildroot-built
>> toolchains meet that anyway). Or would it be acceptable to simply say
>> that people with old external toolchains are on their own?
>
> As noted in my filebeat package patch [0], the ld.bfd issue is
> supposedly fixed since binutils 2.36, AFAIUI.

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

> There, I took the approach that the workaround would not be conditional
> on the binutils version. First, because there is no way in Buildroot to
> get that information, especially for external toolchains. Second,
> because using ld.bfd should always work, using ld.gold only being an
> optimnisation at build time.
>
> I also considered that toolchains too old to even have ld.bfd would just
> be ignored anyway. ld.bfd was introduced with ld.gold, which was "quite
> a long time ago" (at least 2011 I believe), so we can assume any rdecent
> toolchain would be recent enough to have it.
>
> 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.

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:

# github.com/containerd/containerd/v2/cmd/containerd
/home/fiona/development/buildroot/output/revpi/host/lib/go/pkg/tool/linux_amd64/link:
running
/home/fiona/development/buildroot/output/revpi/host/bin/aarch64-buildroot-linux-musl-gcc
failed: exit status 1
/home/fiona/development/buildroot/output/revpi/host/bin/aarch64-buildroot-linux-musl-gcc
-Wl,-z,now -Wl,-z,nocopyreloc -fuse-ld=gold -o $WORK/b001/exe/a.out
-rdynamic /tmp/go-link-3508132847/go.o /tmp/go-link-3508132847/000000.o
/tmp/go-link-3508132847/000001.o /tmp/go-link-3508132847/000002.o
/tmp/go-link-3508132847/000003.o /tmp/go-link-3508132847/000004.o
/tmp/go-link-3508132847/000005.o /tmp/go-link-3508132847/000006.o
/tmp/go-link-3508132847/000007.o /tmp/go-link-3508132847/000008.o
/tmp/go-link-3508132847/000009.o /tmp/go-link-3508132847/000010.o
/tmp/go-link-3508132847/000011.o /tmp/go-link-3508132847/000012.o
/tmp/go-link-3508132847/000013.o /tmp/go-link-3508132847/000014.o
/tmp/go-link-3508132847/000015.o /tmp/go-link-3508132847/000016.o
/tmp/go-link-3508132847/000017.o /tmp/go-link-3508132847/000018.o
/tmp/go-link-3508132847/000019.o /tmp/go-link-3508132847/000020.o
/tmp/go-link-3508132847/000021.o /tmp/go-link-3508132847/000022.o
/tmp/go-link-3508132847/000023.o /tmp/go-link-3508132847/000024.o -ztext
-lresolv -ztext -lpthread -ztext -ldl -ztext -fuse-ld=bfd
/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?

Best regards,
Fiona

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