Tag Archives: ldd

ELF Library dependency viewer

Update 2009-10-10: Updated link to software

So after having a Gentoo upgrade break a lot of programs, even after running the revdep-rebuild which rebuilds packages affected by a changed library, I decided that I had to have a way to find out what libraries in particular were causing programs to need to load the affected library. In my case an expat upgrade replaced libexpat.so.0 with libexpat.so.1. Even though revdep-rebuild was supposed to rebuild the affected packages it missed quite a few.

(I would eventually figure out that the reason it messed up is because the lib64 directory is symlinked to lib since I have a 64-bit system. The program would end up linked against a library in /usr/lib64, revdep-rebuild would look for programs linked against the exact same library, but in /usr/lib instead, and then not find it.)

Anyways, after playing around with ldd and discovering that it would not give a nice tree diagram showing what the dependencies of a program was I decided to make a tool that would do so. I call it ELF Library Viewer (elflibviewer on the command line):

Screenshot of the ELF library viewer in action

If it interests you at all it is available from my software page. It requires Qt 4 and the readelf utility to be installed. It doesn’t really do much error handling (i.e. run it on ELF executables and libraries and you’ll be fine) but it shouldn’t ruin your binaries either.

It is rather Linux-specific at this point as well, but it should mirror the GNU binutils way of finding libraries closely. Instead of searching the ld.so cache it checks ld.so.conf to figure out what ld.so should be caching however. Let me know if this program proves useful for you (or if I’m just reinventing the wheel). Bonus tip: Type the name of the offending library into the search line and hit enter. It will highlight in red all of the libraries which depend on the offending library. It also recursively resolves dependencies, but only the first time it sees a library. It probably wouldn’t be too hard to copy over the dependency tree each time it reencounters a library but I can’t be bothered to implement it.