Section: Linux Programmer's Manual (8)
The dynamic linker can be run either indirectly by running some dynamically linked program or library (in which case no command-line options to the dynamic linker can be passed and, in the ELF case, the dynamic linker which is stored in the .interp section of the program is executed) or directly by running:
The programs ld.so and ld-linux.so* find and load the shared libraries needed by a program, prepare the program to run, and then run it.
The program ld.so handles a.out binaries, a format used long ago; ld-linux.so* handles ELF (/lib/ld-linux.so.1 for libc5, /lib/ld-linux.so.2 for glibc2), which everybody has been using for years now. Otherwise, both have the same behavior, and use the same support files and programs ldd?(1), ldconfig?(8), and /etc/ld.so.conf.
When resolving library dependencies, the dynamic linker first inspects each dependency string to see if it contains a slash (this can occur if a library pathname containing slashes was specified at link time). If a slash is found, then the dependency string is interpreted as a (relative or absolute) pathname, and the library is loaded using that pathname.
If a library dependency does not contain a slash, then it is searched for in the following order:
ld.so understands certain strings in an rpath specification (DT_RPATH or DT_RUNPATH); those strings are substituted as follows
so that it finds an associated shared library in somedir/lib no matter where somedir is located in the directory hierarchy. This facilitates the creation of "turn-key" applications that do not need to be installed into special directories, but can instead be unpacked into any directory and still find their own shared libraries.
Some libraries are compiled using hardware-specific instructions which do not exist on every CPU. Such libraries should be installed in directories whose names define the required hardware capabilities, such as /usr/lib/sse2/. The dynamic linker checks these directories against the hardware of the machine and selects the most suitable version of a given library. Hardware capability directories can be cascaded to combine CPU features. The list of supported hardware capability names depends on the CPU. The following names are currently recognized:
Among the more important environment variables are the following:
LD_ASSUME_KERNEL can be used to cause the dynamic linker to assume that it is running on a system with a different kernel ABI version. For example, the following command line causes the dynamic linker to assume it is running on Linux 2.2.5 when loading the shared libraries required by myprog:
$ LD_ASSUME_KERNEL=2.2.5 ./myprog
On systems that provide multiple versions of a shared library (in different directories in the search path) that have different minimum kernel ABI version requirements, LD_ASSUME_KERNEL can be used to select the version of the library that is used (dependent on the directory search order). Historically, the most common use of the LD_ASSUME_KERNEL feature was to manually select the older LinuxThreads POSIX threads implementation on systems that provided both LinuxThreads and NPTL (which latter was typically the default on such systems); see pthreads?(7).
Then there are lots of more or less obscure variables, many obsolete or only for internal use.
The dynamic linker will notify the audit libraries at so-called auditing checkpoints---for example, loading a new library, resolving a symbol, or calling a symbol from another shared object---by calling an appropriate function within the audit library. For details, see rtld-audit?(7). The auditing interface is largely compatible with that provided on Solaris, as described in its Linker and Libraries Guide, in the chapter Runtime Linker Auditing Interface.
This page is part of release 3.74 of the Linux man-pages project. A description of the project, information about reporting bugs, and the latest version of this page, can be found at http://www.kernel.org/doc/man-pages/.
Tutoriais de Tecnologia Web