This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |