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 the default directory /usr/lib (for 32–bit objects), or /usr/lib/64 (for 64–bit objects), then the runtime linker must explicitly be told where to look. The preferred mechanism of indicating any requirement of this kind is to record a runpath in the object that has the dependencies 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
$ dump -Lv libfoo.so

libfoo.so:

  **** DYNAMIC SECTION INFORMATION ****
.dynamic:
[INDEX] Tag      Value
[1]     NEEDED   libbar.so
[2]     RUNPATH  /home/me/lib
.........

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

The environment variable LD_LIBRARY_PATH has a more global scope. Any path names specified using this variable 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 this environment variable is strongly discouraged in production software. See Directories Searched by the Runtime Linker for a more extensive discussion.