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.

18 thoughts on “ELF Library dependency viewer

  1. Soap Identicon Soap

    It’s not just the lib vs lib64 thing. I’ve had similar issues on my 32-bit system (after running revdep-rebuild).

    To solve it, I usually just emerge the affected package when I discover it. If I don’t have time for that, I symlink the library temporarily, and hope it works.

    Your solution looks very useful.

  2. Diederik van der Boo Identicon Diederik van der Boo

    Cool to see a graphical frontend for this! This could also be a nice addition for this bugreport:

    I’m curious, does the following command also return what you need:
    objdump -x `which binary` | grep NEEDED

    That command only shows the direct dependencies. This happens when the system is compiled with `ld –as-needed`. Using it increases startup time, and avoids unnecessary breaks with applications which don’t link to the library directly.

  3. Fred Identicon Fred

    In an FHS-compliant multilib x86_64 system, /usr/lib64 should not be symlinked to /usr/lib – instead /usr/lib should contain 32-bit binaries.

  4. Leo S Identicon Leo S

    Neat. This could be very useful.
    I wonder why your screenshot shows so many dependencies on X libs in the top level. I ran it against my program and it only has qtgui/network/sql/core and the libc/stdc++/pthread stuff. Only 10 first level dependencies overall..

  5. Leo S Identicon Leo S

    Actually I just tried loading elflibviewer and it only shows 7 dependencies. I wonder what’s different between yours and mine.

  6. yokem55 Identicon yokem55

    This would have been a HUGE help a couple of months ago when the whole expat upgrade mess hit. I spent hours trying to figure out which library that kde linked to was missing the right expat.so version. I ended up just rebuilding kde.

  7. mpyne Identicon mpyne Post author

    Diederik: objdump works just fine as well (i.e. objdump -p -j .dynamic `which kfoo`). I just happened to notice that readelf does what I want first.

    All: Sorry about comments not posting. I’ll try and loosen the anti-spamming measures.

  8. mpyne Identicon mpyne Post author

    I’ve enabled a few more spam fighting plugins and disabled moderation. For the first time ever I’m running a blog that not only supports comments, but will immediately add said comment to the post. We’ll see how this works.

    I’ve been trying to avoid plugins that require JavaScript to work (one requires JS but can fail gracefully with extra user intervention). Hopefully I won’t have to eventually have to go the route of requiring JS to try and weed out bots.

  9. mpyne Identicon mpyne Post author

    Leo: I suspect the difference in the number of dependencies is due to the –as-needed flag which was mentioned early. I didn’t add that flag explicitly and I’m not sure if CMake does auto-detection for it (I doubt it since it apparently breaks on a couple of programs which have been mis-linked but worked since they indirectly depended on the libraries in question).

  10. Pingback: ELF Lib Viewer « Gergap’s Weblog

Comments are closed.