Shared Objects With Dependencies

Shared objects can have their own dependencies. The search rules used by the runtime linker to locate shared object dependencies are covered in Directories Searched by the Runtime Linker. If a shared object does not reside in one of the default search directories, then the runtime linker must explicitly be told where to look. For 32–bit objects, the default search directories are /lib and /usr/lib. For 64–bit objects, the default search directories are /lib/64 and /usr/lib/64. The preferred mechanism of indicating the requirement of a non-default search path, is to record a runpath in the object that has the dependencies. A runpath can be recorded by using the link-editor's -R option.

In the following example, the shared object libfoo.so has a dependency on libbar.so, which is expected to reside in the directory /home/me/lib at runtime or, failing that, in the default location.

$ cc -o libbar.so -G -K pic bar.c
$ cc -o libfoo.so -G -K pic foo.c -R/home/me/lib -L. -lbar
$ elfdump -d libfoo.so | egrep "NEEDED|RUNPATH"
       [1]  NEEDED        0x123         libbar.so.1
       [2]  RUNPATH       0x456         /home/me/lib

The shared object is responsible for specifying all runpaths required to locate its dependencies. Any runpaths specified in the dynamic executable are only used to locate the dependencies of the dynamic executable. These runpaths are not used to locate any dependencies of the shared objects.

TheLD_LIBRARY_PATH family of environment variables have a more global scope. Any path names specified using these variables are used by the runtime linker to search for any shared object dependencies. Although useful as a temporary mechanism that influences the runtime linker's search path, the use of these environment variables is strongly discouraged in production software. See Directories Searched by the Runtime Linker for a more extensive discussion.