ELF Library dependency viewer
October 24th 2007 08:31 pm
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):
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.
Neat !
Man!!! “Gentoo-related” stuff, great… Love it…
Great tool to help with these sort of issues.
Nice work.
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.
Kinda cool. Would make a great addition to the properties-dialog of executables!
Cool to see a graphical frontend for this! This could also be a nice addition for this bugreport:
http://bugs.kde.org/show_bug.cgi?id=127728
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.
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.
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..
Actually I just tried loading elflibviewer and it only shows 7 dependencies. I wonder what’s different between yours and mine.
Very cool. You need something like this more often than most people realise.
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.
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.
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.
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).
One last thing, I asked about reinventing the wheel, turns out there’s already a script out to do much the same job. It looks good but depends on a lot of stuff that makes me not feel like installing it right now.
http://wiki.tfkyle.dyndns.org/wiki/DepSpec
Michael,
are you aware of “visual-ldd”? Like in http://unix.freshmeat.net/projects/visual_ldd/ (freshmeat) and in http://unix.freshmeat.net/screenshots/54133/58133/ (screenshot) and in http://cvs.sunsite.dk/viewcvs.cgi/autopackage/visual-ldd/ (source code repository)?
Cheers,
Kurt
ELF Lib Viewer « Gergap’s Weblog responded on 13 Aug 2008 at 12:47 #
[...] googled a little bit and found a nice Qt based tool called ELFLibViewer which does the same job for ELF binaries on [...]