динамический компоновщик / загрузчик (dynamic linker/loader)
Имя (Name)
ld.so, ld-linux.so - dynamic linker/loader
Синопсис (Synopsis)
The dynamic linker can be run either indirectly by running some
dynamically linked program or shared object (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:
/lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]]
Описание (Description)
The programs ld.so and ld-linux.so* find and load the shared
objects (shared libraries) needed by a program, prepare the
program to run, and then run it.
Linux binaries require dynamic linking (linking at run time)
unless the -static option was given to ld(1) during compilation.
The program ld.so handles a.out binaries, a binary format used
long ago. The program ld-linux.so* (/lib/ld-linux.so.1 for
libc5, /lib/ld-linux.so.2 for glibc2) handles binaries that are
in the more modern ELF format. Both programs have the same
behavior, and use the same support files and programs (ldd(1),
ldconfig(8), and /etc/ld.so.conf).
When resolving shared object dependencies, the dynamic linker
first inspects each dependency string to see if it contains a
slash (this can occur if a shared object 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 shared object is loaded using that pathname.
If a shared object dependency does not contain a slash, then it
is searched for in the following order:
o Using the directories specified in the DT_RPATH dynamic
section attribute of the binary if present and DT_RUNPATH
attribute does not exist. Use of DT_RPATH is deprecated.
o Using the environment variable LD_LIBRARY_PATH, unless the
executable is being run in secure-execution mode (see below),
in which case this variable is ignored.
o Using the directories specified in the DT_RUNPATH dynamic
section attribute of the binary if present. Such directories
are searched only to find those objects required by DT_NEEDED
(direct dependencies) entries and do not apply to those
objects' children, which must themselves have their own
DT_RUNPATH entries. This is unlike DT_RPATH, which is applied
to searches for all children in the dependency tree.
o From the cache file /etc/ld.so.cache, which contains a
compiled list of candidate shared objects previously found in
the augmented library path. If, however, the binary was
linked with the -z nodeflib linker option, shared objects in
the default paths are skipped. Shared objects installed in
hardware capability directories (see below) are preferred to
other shared objects.
o In the default path /lib, and then /usr/lib. (On some 64-bit
architectures, the default paths for 64-bit shared objects are
/lib64, and then /usr/lib64.) If the binary was linked with
the -z nodeflib linker option, this step is skipped.
Dynamic string tokens
In several places, the dynamic linker expands dynamic string
tokens:
o In the environment variables LD_LIBRARY_PATH, LD_PRELOAD, and
LD_AUDIT,
o inside the values of the dynamic section tags DT_NEEDED,
DT_RPATH, DT_RUNPATH, DT_AUDIT, and DT_DEPAUDIT of ELF
binaries,
o in the arguments to the ld.so command line options --audit,
--library-path, and --preload (see below), and
o in the filename arguments to the dlopen(3) and dlmopen(3)
functions.
The substituted tokens are as follows:
$ORIGIN (or equivalently ${ORIGIN})
This expands to the directory containing the program or
shared object. Thus, an application located in
somedir/app could be compiled with
gcc -Wl,-rpath,'$ORIGIN/../lib'
so that it finds an associated shared object 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 objects.
$LIB (or equivalently ${LIB})
This expands to lib or lib64 depending on the architecture
(e.g., on x86-64, it expands to lib64 and on x86-32, it
expands to lib).
$PLATFORM (or equivalently ${PLATFORM})
This expands to a string corresponding to the processor
type of the host system (e.g., "x86_64"). On some
architectures, the Linux kernel doesn't provide a platform
string to the dynamic linker. The value of this string is
taken from the AT_PLATFORM value in the auxiliary vector
(see getauxval(3)).
Note that the dynamic string tokens have to be quoted properly
when set from a shell, to prevent their expansion as shell or
environment variables.
