The LD_LIBRARY_PATH environment variable contains a colon separated list of paths that the linker uses to resolve library dependencies of ELF executables at run-time. These paths will be given priority over the standard library paths /lib and /usr/lib. The standard paths will still be searched, but only after the list of paths in LD_LIBRARY_PATH has been exhausted.

The best way to use LD_LIBRARY_PATH is to set it on the command line or script immediately before executing the program. This way you can keep the new LD_LIBRARY_PATH isolated from the rest of your system.

$ export LD_LIBRARY_PATH="/list/of/library/paths:/another/path"
$ ./program

In general it is not a good practice to have LD_LIBRARY_PATH permanently set in your environment. This could lead to unintended side effects as programs can link to unintended libraries producing strange results or unexpectedly crashing. There is also the possibility introducing potential security threats.

All those warnings aside, if you are using BASH you can set it permanently by placing a line similar to this in your .bashrc in your home directory.

export LIBRARY_PATH="/list/of/library/paths:/another/path"

A common case for setting LD_LIBRARY_PATH is when you have an application that requires dynamic libraries which were not installed in the standard library locations.

You can check if the linker can locate all the required libraries by running the ldd command.

$ 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

The linker cannot find libmylib.so.1.

Let’s assume this library exists here “~/myprogdir/lib/libmylib.so.1″. We have to set LD_LIBRARY_PATH to include this path for the application to successfully run.

$ export LD_LIBRARY_PATH="~/myprogdir/lib/:$LD_LIBRARY_PATH"
$ 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 => ~/myprogdir/lib/libmylib.so.1 (0x00002b4eca9fa000)

The linker has now found all the required libraries.

Related posts

1. View dynamic library dependencies with ldd
2. Select threading implementation using LD_ASSUME_KERNEL
3. How to get Boxee to correctly identify local media files

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.

Related posts

1. How to correctly use LD_LIBRARY_PATH
2. List all open files with lsof
3. View process environment details with proc