View dynamic library dependencies with ldd

The ldd command allows you to view detailed information about library dependencies of dynamically linked programs and other shared libraries. ldd uses the runtime linker ld.so which reads the ELF formatted executable to generate the output. It is a helpful tool to have at your disposal when debugging broken programs.

Here ldd examines the ‘ls’ executable. The output displays the dependencies as well as how they will be resolved if run with the current environment.

$ ldd /bin/ls

	linux-vdso.so.1 =>  (0x00007fffe0dfe000)
	librt.so.1 => /lib/librt.so.1 (0x00002b4eca08e000)
	libacl.so.1 => /lib/libacl.so.1 (0x00002b4eca297000)
	libc.so.6 => /lib/libc.so.6 (0x00002b4eca49f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00002b4eca7df000)
	/lib64/ld-linux-x86-64.so.2 (0x00002b4ec9e72000)
	libattr.so.1 => /lib/libattr.so.1 (0x00002b4eca9fa000)

Sometimes you will see that an application can’t resolve one or more libraries. It would most likely fail to execute at this moment if you see a “not found” entry like this.

$ ldd ~/myprogram

	librt.so.1 => /lib/librt.so.1 (0x00002b4eca08e000)
	libc.so.6 => /lib/libc.so.6 (0x00002b4eca49f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00002b4eca7df000)
	/lib64/ld-linux-x86-64.so.2 (0x00002b4ec9e72000)
	libmylib.so.1 => not found

To resolve these type of issues you can either install the missing libraries, or if they are already installed, update the LD_LIBRARY_PATH environment variable with the path to the libraries.

Once you have done one of these two things, rerun ldd on the executable and verify that the library dependency can now be correctly resolved.

One last caveat, ldd will not display information about shared libraries that the program may try to open using the glibc function dl_open() during its execution.