On Thu, Nov 04, 2021 at 10:56:04AM +0100, Florian Weimer wrote:
* Luca Boccassi:
>> * Zbigniew Jędrzejewski-Szmek:
>>
>>
>> The general case of any statically linked code. It could be libgcc,
>> startup files, the non-shared bits of glibc, static-only libraries, or
>> header-only C++ libraries.
> This would be indeed useful, but quite harder to do automagically I
> think?
It requires some level of toolchain support, in compilers and linkers.
It's unlikely that this would use a JSON-based approach, though. I
think what we want in the linker for this is that it de-duplicates and
merges individual artifact identifiers, so that one ends up with a
single string "glibc-2.34-7.fc35" instead of multiple copies of it. But
I can't see us implementing JSON processing in the linker (all four of
them).
Maybe this should be done at different level altogether: rpms have
dynamically generated requires/provides. Maybe we should have something
as part of the build process that generates 'Provides: bundled(foo) = …'
for every package that provides "static elements" that is present on
the build system / or listed in build requires if that'd be possible.
(Packages that provide "static elements" would be those that have -static
in the name or are header only -devel packages. We could use some heuristics
and/or mark them appropriate using virtual Provides.)
This would probably be a lot easier to implement than a language that
is embedded in ELF files… It could also be made to work for some
strange cases like a .jar file embedding an .so.
Zbyszek