[Rpm-maint] [rpm-software-management/rpm] rpmdeps makes bad assumption when parsing ELF files (Issue #1887)

[Ross Burton]

I experimented with the mold linker (https://github.com/rui314/mold) but we were getting packaging failures due to some libraries not having their Provides set correctly (ie libgmodule was no longer providing `libgmodule.so.1(64-bit)`).

It turns out that the cause was that `rpmdeps`  uses the presence of the `DT_DEBUG` dynamic entry to determine if a given object is a shared library or an executable, and mold was always writing an entry.

Since https://github.com/rui314/mold/commit/60c134893ca2349d33e9cac6b748425ebf5da3af mold only generates these for executables, but this is fundamentally a bad way to identify library vs executable.

The mold maintainer suggests instead:
> 1. Look for DT_FLAGS_1 dynamic section entry
> 2. Check if DF_1_PIE bit is set. If set, it's position-independent executable. Otherwise shared object file.
>
> If DT_FLAGS_1 entry is not present, I believe you can safely assume that that's a shared object file.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/1887
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/1887 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20220117/ff272339/attachment.html>