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

[yann.morin@orange.com]

Christian, All,

On 2025-02-05 01:20 -0800, Christian Stewart spake thusly:
> On Wed, Feb 5, 2025, 12:29 AM < [1]yann.morin@orange.com> wrote:
>   So, I guess you only actually suggested moving setting -fuse-ld=bfd and
>   -Wl,--no-pie flags into pkg-golang, right?
> My thinking is that we always want Go to have fuse-ld set to the correct "ld" we are using. So it makes sense to set this in
> pkg-golang.
> This way any new packages that have dynamic linking (cgo) will also pick up the fix as needed.

OK, that is for -fuse-ld=bfd. That makes sense.

What about -Wl,--no-pie, then? Does it also make sense to have in the
infra as well?

>   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).
> It is just because it uses cgo, or am I wrong?

TBH, I just banged on it until it build and run. If cgo is the reason we
need to pass -fuse-ld=bfd, then that should be part of the condition,
no? i.e., something like (in pkg-golang.mk):

    ifeq ($$(BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS),y)
    ifeq ($$(BR2_aarch64),y)
    $(2)_EXTLDFLAGS += -fuse-ld=bfd
    endif  # AArch64
    endif  # CGO linking

Or can we just pass it unconditionally, even if it is actually not going
to be used? I.e. do we need any condition at all, evem the AArch64 one?

If we want to introduce that assignment in the infra, we need to get as
much insights as possible to explain it, and we need to get affirmative
statements as to how we should set it.

I guess my patch adding FOO_EXTLDFLAGS would not change, but Fiona will
need that info if she is to respin a fix for containerd's build failure.

[--SNIP--]
>   Still, I believe there should be a way for packages to be able to pass
>   arbitrary extldflags, and thus the variable should be exposed.
> Yes, that variable should be exposed, I agree. It's useful to be able to pass extra ld flags as needed.

ACK, thanks for the feeback!

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