Tracing linked libraries

Question

I'm getting some errors which make me think that my Linux program isn't linking to the libraries it's supposed to. How can I get the full path to all linked libraries? I know ldd will give me the names, but how can I use that to get the full path?

Thanks.

Answer 1

Actually ldd gives you absolute path with filename of whatever from your application's shared library dependencies it's able to find.

    $ ldd v8test 
    linux-gate.so.1 =>  (0xb78b2000)
    libz.so.1 => /usr/lib/libz.so.1 (0xb787e000)
    librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb7875000)
    libcppunit-1.12.so.1 => /usr/lib/libcppunit-1.12.so.1 (0xb782c000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7604000)
    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb75dd000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb75bf000)
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7478000)
    libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb745f000)
    libboost_system-mt.so.1.38.0 => /usr/lib/libboost_system-mt.so.1.38.0 (0xb745b000)
    /lib/ld-linux.so.2 (0xb78b3000)
    libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7456000)
    libboost_thread-mt.so.1.38.0 => /usr/lib/libboost_thread-mt.so.1.38.0 (0xb7383000)
    libboost_filesystem-mt.so.1.38.0 => /usr/lib/libboost_filesystem-mt.so.1.38.0 (0xb7370000)
    libtinyxml.so.1 => /home/dmitry/tinyxml/libtinyxml.so.1 (0xb7359000)
    libboost_regex-mt.so.1.38.0 => /usr/lib/libboost_regex-mt.so.1.38.0 (0xb728c000)
    libmysqlclient_r.so.15 => /usr/lib/libmysqlclient_r.so.15 (0xb70a1000)
    libicuuc.so.42 => /usr/lib/libicuuc.so.42 (0xb6f61000)
    libicudata.so.42 => /usr/lib/libicudata.so.42 (0xb601a000)
    libicui18n.so.42 => /usr/lib/libicui18n.so.42 (0xb5e6b000)
    libcrypt.so.1 => /lib/i686/cmov/libcrypt.so.1 (0xb5e39000)
    libnsl.so.1 => /lib/i686/cmov/libnsl.so.1 (0xb5e22000)

The libraries are searched by its soname (e.g. libboost_filesystem-mt.so.1.38.0) in paths mentioned in /etc/ld.so.conf, LD_LIBRARY_PATH or set with rpath in the binary itself.

If ldd is unable to find something it will look like

    libicuuc.so.42 => not found

In this case consider using one of the mentioned ways to give correct search path.

ldd will warn you when it's unable to load the library due to some reason.

$ ldd v8test 
./v8test: error while loading shared libraries: /home/dmitry/a/liba.so.2: invalid ELF header

Of course it can't protect you from the errors in the library itself. In fact it's possible your application to depend on libraries A and B, both depending on incompatible versions on some library C. In this situation your program has a good chance to crash (unless library C doesn't have symbol versioning) - ldd is not going to warn you, but you should be able to see it in the output.

Program-Library-HOWTO will be useful for you.

Check also some options of ldd or dynamic linker.