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 executable are only used to locate the dependencies of the executable. These runpaths are not used to locate any dependencies of the shared objects.
The LD_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 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.