----------------------------------------------------------------------------

Shared object dependencies

When the link editor processes an archive library, it extracts library
members and copies them into the output object file. These statically linked
services are available during execution without involving the dynamic
linker. Shared objects also provide services, and the dynamic linker must
attach the proper shared object files to the process image for execution.
Thus executable and shared object files describe their specific
dependencies. For further information, see ``Link editing'' in the
Programming Tools Guide.

When the dynamic linker creates the memory segments for an object file, the
dependencies (recorded in DT_NEEDED entries of the dynamic structure) tell
what shared objects are needed to supply the program's services. By
repeatedly connecting referenced shared objects and their dependencies, the
dynamic linker builds a complete process image. When resolving symbolic
references, the dynamic linker examines the symbol tables with a
breadth-first search. It first looks at the symbol table of the executable
program itself, then at the symbol tables of the DT_NEEDED entries (in
order), and then at the second level DT_NEEDED entries.

----------------------------------------------------------------------------
NOTE: Even when a shared object is referenced multiple times in the
dependency list, the dynamic linker will connect the object only once to the
process.
----------------------------------------------------------------------------

Names in the dependency list are copies either of the DT_SONAME strings or
the path names of the shared objects used to build the object file. For
example, if the link editor builds an executable file using one shared
object with a DT_SONAME entry of lib1 and another shared object library with
the path name /usr/lib/lib2, the executable file will contain lib1 and
/usr/lib/lib2 in its dependency list.

If a shared object name has one or more slash (/) characters anywhere in the
name, such as /usr/lib/lib2 or directory/file, the dynamic linker uses that
string directly as the path name. If the name has no slashes, such as lib1,
three facilities specify shared object path searching, with the following
caveats:

  1. The dynamic array tag DT_RPATH may give a string that holds a list of
     directories, separated by colons (:). For example, the string
     /home/dir/usr/lib:/home/dir2/usr/lib: tells the dynamic linker to
     search first the directory /home/dir/lib, then /home/dir2/usr/lib, and
     then the current directory to find dependencies.

  2. A variable called LD_LIBRARY_PATH in the process environment may hold a
     list of directories as above, optionally followed by a semicolon (;)
     and another directory list. The following values would be equivalent to
     the previous example:

        o LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:

        o LD_LIBRARY_PATH=/home/dir/usr/lib;/home/dir2/usr/lib:

        o LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:

     All LD_LIBRARY_PATH directories are searched after those from DT_RPATH.
     Although some programs (such as the link editor) treat the lists before
     and after the semicolon differently, the dynamic linker does not.
     Nevertheless, the dynamic linker accepts the semicolon notation, with
     the semantics described previously.

  3. If the other two groups of directories fail to locate the desired
     library, the dynamic linker searches /usr/lib.

----------------------------------------------------------------------------
NOTE: For security, the dynamic linker ignores environmental search
specifications (such as LD_LIBRARY_PATH) for set-user and set-group ID
programs. It does, however, search DT_RPATH directories and /usr/lib.
----------------------------------------------------------------------------