Re: [PATCH] ld: add --package-metadata

[Florian Weimer <fweimer@redhat.com>]

* Fangrui Song:

> On 2022-05-17, Luca Boccassi via Binutils wrote:
>>On Tue, 17 May 2022 at 07:03, Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * Fangrui Song:
>>>
>>> > Both the "FDO" and the json dependency make me concerned -
>>> > if a linker script approach works quite well, why bother with a new
>>> > linker option with a very specific application?
>>>
>>> The linker script does not work all that well because it requires that
>>> the script is materialized to disk somewhere, and that path needs to
>>> show up in the build flags.  If the build flags are stored beyond the
>>> build for future use, this makes them invalid because the path will
>>> typically be gone by the time the stored flags are used.
>>>
>>> Thanks,
>>> Florian
>
> Do you mean that a user may need to re-link the executable/shared
> object? The note content must be preserved somewhere, I don't see how
>
> as ... -o meta.o
> ld.bfd ... meta.o
>
> is more inconvenient than
>
> ld.bfd --package-meta='content' ...

If the object file is put into /build/builddir/BUILD/foo-12.3/meta.o,
the full path ends up in LDFLAGS.  (The validity of a relative path
would depend on the package-specific build system.)  But if we do that,
and the package build system captures LDFLAGS into some generated
artifact that controls link editor invocation, it may try to link with
/build/builddir/BUILD/foo-12.3/meta.o.  But that file will no longer
exist at the time.

> The "FDO" owner also makes me concerned. It seems a bit arbitrary.

It's the usual abbreviation for freedesktop.org, where the specification
lives.

> https://src.fedoraproject.org/rpms/package-notes/pull-request/2#comment-98855 (tstellar)
> says
> "Given, that I'm the maintainer of lld in Fedora, if I volunteer to deal
> with issues that stem from this assembler based implementation would you
> be more likely to accept this patch?"
>
> It would be nice to have a list of packages and fix them (perhaps
> issues like not honor LDFLAGS).

I think this is unrelated to honoring LDFLAGS or not.

Thanks,
Florian