(not) simplifying dpkg-shlibdeps with readelf
Raphael Hertzog wrote:
> On Wed, 21 Apr 2010, Jonathan Nieder wrote:
>> If we can, dpkg-shlibdeps could be simplified a lot by using readelf
>> instead of objdump. That’s something I would enjoy doing.
>
> In what way do you expect simplifications ?
That was sloppy of me; sorry.
Even if all supported targets use ELF, I don’t think it would justify
the churn. The main advantages:
- readelf is tiny and works for all ELF targets.
By contrast, multi-target objdump is large and its Debian package
only supports the targets that were considered worth the trouble
when it was last built.
- ELF is lower-level and objdump does not use an abstraction that
matches up well with what dpkg-shlibdeps needs. So using readelf
would make it easier to verify that dpkg-shlibdeps is doing the
right thing.
Consider on the other hand the potential for breakage and it doesn’t
sound so good. I am including what I was thinking about below
for reference [1].
Sorry for the nonsense.
Jonathan
[1] To discover SONAME, NEEDED, RUNPATH, and RPATH, one could parse
‘eu-readelf --dynamic $file’ output. The output is very similar to
that of ‘objdump --private-headers’. Explicitly using the dynamic
section just has more obvious behavior (and would make it easier to
switch to using libelf or similar later if that seems to be a good
idea).
To simulate linking in order to find shlibs files, it would be nice
to find a way to use ldd (and enhance it in places where it is not
helpful enough, like considering binaries for other platforms).
Barring that, a first approximation which is a little stricter than
the current dpkg-shlibdeps rules would be to could compare the ELF
class, OS ABI version, userspace ABI version, and machine type from
‘eu-readelf --file-header $file’.
Reply to: