Hierarchical ldd(1)

Question

Due to using Gentoo, it often happens that after an update programs are linked against old versions of libraries. Normally, revdep-rebuild helps resolving that, but this time it's a dependency on a python library, and python-updater won't pick it up.

Is there a "hierarchical" variant of ldd which shows me what shared library depends on which another shared library? Most of the time libraries and executables are linked only against a handful of other shared libraries, which in turn were linked against a handful, turning the library dependency into a big list. I want to know which dependency I've got to rebuild with the new version of another library that I upgraded.

Answer 1

I see many interesting details but no direct answer to the question asked.

The 'hierarchical' version of ldd is lddtree (from app-misc/pax-utils):

$ lddtree /usr/bin/xmllint  xmllint => /usr/bin/xmllint (interpreter => /lib64/ld-linux-x86-64.so.2)     libreadline.so.6 => /lib64/libreadline.so.6         libncurses.so.5 => /lib64/libncurses.so.5             libdl.so.2 => /lib64/libdl.so.2     libxml2.so.2 => /usr/lib64/libxml2.so.2         libicui18n.so.49 => /usr/lib64/libicui18n.so.49             libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libstdc++.so.6                 ld-linux.so.2 => /lib64/ld-linux.so.2             libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/32/libgcc_s.so.1         libicuuc.so.49 => /usr/lib64/libicuuc.so.49         libicudata.so.49 => /usr/lib64/libicudata.so.49         libz.so.1 => /lib64/libz.so.1         liblzma.so.5 => /usr/lib64/liblzma.so.5         libm.so.6 => /lib64/libm.so.6     libpthread.so.0 => /lib64/libpthread.so.0     libc.so.6 => /lib64/libc.so.6