[PATCH v4] ld: Add --encoded-package-metadata

[Matthias Klose]

On 25.07.24 12:35, H.J. Lu wrote:
> On Thu, Jul 25, 2024, 6:00 PM Nick Clifton <nickc@redhat.com> wrote:
> 
>> Hi Jan, Hi Benjamin, Hi Matthias
>>
>>>> So introduce a `--encoded-package-metadata` linker flag that takes a
>>>> percent-encoded JSON. Percent-encoding is used because it is a
>>>> standard and simple to implement.
>>>
>>> Okay. Please don't forget to add a reference to the PR that you created
>>> upon H.J.'s request. I notice H.J. has voiced a readability concern
>>> there, but I think that can be taken care of incrementally.
>>>
>>> Cc-ing Nick as to views towards putting this on the branch as well.
>>
>> Hmm, I am open to the idea, but only if the commit (to the mainline)
>> happens this week.  That will give me enough time to backport the
>> patch and test it on the 2.43 branch.
>>
> 
> I don't think this option is human readable.
> It is a bad approach.

does it have to be human readable?  This option is always auto-generated 
by some packaging system.  The value is checked in the linkers to be a 
valid json file. What is needed is a way to propagate that information 
down to the linker.

  - The current approach taken by Fedora to pass a --specs option
    to the compiler, and constructing the --package-metadata
    in a new link spec using the getenv function for the GCC specs
    doesn't work
     + for compilers other than GCC
     + for debugging, when not every env var required in the
       specs file is set, and the compiler bailing out with
       an error. You would have to remove the --specs option
       from generated Makefiles, and then dealing with
       the build system rebuilding these generated Makefiles.

  - The current option --package-metadata is not good enough,
    it's too fragile with the characters interpreted by various
    shells and build systems, also options are saved in some
    way in build artifacts.  You cannot assume to fix/change
    every build system.
    I assume the Fedora people saw that as well, and then
    introduced the new specs.

  - --encoded-package-metadata tries to resolve this by making the
    option values robust. Sure, you can go with the existing option
    and accepting some encoded option value as well. I wouldn't care
    that much about compatibility, because the injection of that
    option in the build system and having that option available in
    the linkers is almost always in the hands of the same people,
    e.g distribution maintainers.

  - I want to go further for cases, where the option is lost in
    some place, the build system not passing that option down to
    the linker for some reason.
    For these cases I consider to have something similar like
    the SOURCE_DATE_EPOCH envvar, like ELF_PACKAGE_METADATA,
    and the linkers picking up this envvar if it exists, and if
    no package-metadata option is given.  I am currently thinking
    to have this as a local patch in the distros, but if the
    upstreams think that is useful to have upstream, I'll
    submit patches for this as well.

    This alternative pics up the metadata information from the
    environment in one piece, not like the Fedora approach of
    picking up five different envvars in the specs file, and then
    failing in the compiler if something is unset.

I don't think, that many people have been asked or involved with this 
metadata thing, and how this information is supposed to get there.  It 
seems mostly a Fedora/Systemd thing.  Benjamin is currently trying to 
get that information into Ubuntu, and I'm also trying to get this into 
Debian, when we see a viable approach without too many glitches.

Matthias