I noticed someone encountered an issue with trying to find out what library is introducing dependencies into their program, and didn’t immediately think of a tool I’d written to do that, so obviously I am not “marketing” effectively. ;)
I wouldn’t bother trying to ride Robin’s coattails except that some of the issues he notes (repeated dependencies, search paths) should be implemented already in mine. Oh, and mine is GUI driven in case you’re of that persuasion (not that there’s anything wrong with CLI!)
Without further ado, ELF Library Viewer:
Please go easy on the screenshot, it’s been unchanged for a couple of years now. I’ve only just now confirmed that it even still builds.
As usual, no (coding) progress happens for me unless something else is causing me problems on my system. In this case, I had the opportunity to need to use my library dependency viewer.
Qt is nice enough to link to KIO when run under a KDE desktop, so even though ELF Library Viewer only links to Qt right now, I still get the nice KDE file open dialog. This is 99% of the time a positive feature. But for some reason the dialog was crashing and just having a horrible time handling large directories (like, say, /usr/bin). Worse yet, I couldn’t simply type /usr/bin/foo and click OK, since that isn’t working either. Hmm.
I decided the easiest thing to do would be to add support for opening files passed to the command line of my application (and I was right). Since I was working on it anyways I also ported the build system to CMake (from QMake), and so now it’s possible to install it/make packages/etc.
I’ve placed the updated version on my software page in case anyone’s interested. Obligatory screenshot is the same as two years ago:
Now it’s back to reading research papers all day. :-/
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.