Interface to resolve SONAMES, ld.so.cache format

[Mike Frysinger]

On Sun 27 Apr 2014 12:25:16 Carlos O'Donell wrote:
> On Sun, Apr 27, 2014 at 5:12 AM, Álvaro Acción Montes wrote:
> > So my current approach is as follows. I get a list of required
> > dependencies
> > by iterating the .dynamic section of the executable and getting all the
> > entries that are tagged as DT_NEEDED. The next step would be to find the
> > shared objects with SONAME's matching the previous list. At this point, I
> > was left wondering if there was a way to obtain them other than parsing
> > ld.so.cache, but I had not luck. Correct me if I'm wrong, but it seems
> > that
> > the linker is a completely isolated entity, and the only functionality
> > exported is via ldopen() function family.
> 
> You do not need to parse ld.so.cache. You *do* need to parse
> ld.so.conf in order to determine where the dynamic linker will search
> for shared libraries.

keep in mind that ld.so.conf can support "include" directives

> You also need to read each ELF file and look for
> DT_SONAME to determine the soname of that shared library.

is this really true ?  pretty sure the ldso doesn't do this.  what it does do 
is look at DT_NEEDED for file names, then searches the paths for that 
filename.  whether the file it finds under that name actually has DT_SONAME 
set to the same value isn't checked.  i think only ldconfig really uses that 
when generating symlinks ?

> You then
> need to follow the normal ELF rules and keep recursively finding all
> the DSOs that would be needed to form the final application image.

such as respecting DT_RPATH/DT_RUNPATH, and the LD_LIBRARY_PATH

in case it's useful, i maintain a python lddtree.py:
http://sources.gentoo.org/gentoo-projects/pax-utils/lddtree.py?view=markup
it produces better output (imo) than ldd, and it does so by following the ELF 
spec as opposed to ldd (which loads the file and then looks at what else was 
loaded).  certainly both are useful, but i find people more often want lddtree 
behavior :).  other fun features:
 - because it's python, you can import it and use the ParseELF func to get 
back a resolved list for that ELF
 - it supports sysroots
 - it supports any ELF format (i.e. suitable for checking cross-compiled ELFs)
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/libc-help/attachments/20140802/d8246f8d/attachment.sig>