LD.ELF_SO(1) | General Commands Manual | LD.ELF_SO(1) |
ld.elf_so
—
ld.elf_so
is a self-contained, position independent
program image providing run-time support for loading and link-editing shared
objects into a process' address space. It uses information stored in data
structures within the binary (see
elf(5)) and environment variables
to determine which shared objects are needed. These shared objects are loaded
at a convenient virtual address using the
mmap(2) system call. After all
shared objects have been successfully loaded,
ld.elf_so
proceeds to resolve external references from
both the main program and all objects loaded. Once all required references are
resolved control is passed to the program via its entry point.
ld.elf_so
is loaded is also supplied.
The linker will search for libraries in three lists of paths:
The use of ld.so.conf should be avoided as the setting of a global search path can present a security risk.
Dynamic loading via dlopen(3) uses the DT_RPATH entries of the main binary, independently of which object the call came from.
ld.elf_so
will expand the following
variables if present in the paths:
ld.elf_so
but the kernel support is currently
disabled.kern.ostype
sysctl(3).kern.osrelease
sysctl(3).hw.machine_arch
sysctl(3).Both ${VARIABLE}
and
$VARIABLE
are recognized.
The filename string can be considered free form, however, it will almost always take the form lib<name>.so.<number>, where name specifies the ‘library’ name and number is conceptually the library's major version number.
This name and another of the form lib<name>.so are normally symbolic links to the real shared object which has a filename of the form lib<name>.so.<major>.<minor>[.<teeny>]. This naming convention allows a versioning scheme similar to a.out(5).
ld.elf_so
will perform all necessary relocations
immediately except for relocations relating to the Procedure Linkage Table
(PLT). The PLT is used as a indirection method for procedure calls to globally
defined functions. It allows, through the use of intermediate code, the
delayed binding of a call to a globally defined function to be performed at
procedure call time. This ‘lazy’ method is the default (see
LD_BIND_NOW).
The DT_INIT and DT_FINI entries in the dynamic section specify the
addresses of the initialization and termination functions, respectively, for
the shared object. ld.elf_so
arranges for each
initialization function to be called before control is passed to the program
and for the termination functions to be called by using
atexit(3).
This mechanism is exploited by the system-supplied constructor initialization and destructor code located in /usr/lib/crtbeginS.o and /usr/lib/crtendS.o. These files are automatically included by cc(1) and c++(1) in the list of object-code files passed to ld(1) when building a shared C or C++ object.
ld.elf_so
.
LD_LIBRARY_PATH
LD_PRELOAD
LD_BIND_NOW
LD_DEBUG
ld.elf_so
was compiled with
debugging support (-DDEBUG).The path expansion variables first appeared in Solaris 10, and in NetBSD 5.0.
LD_LIBRARY_PATH
and
LD_PRELOAD
are not honored when executing in a
set-user-ID or set-group-ID environment. This action is taken to prevent
malicious substitution of shared object dependencies or interposition of
symbols.
December 17, 2010 | NetBSD 8.99 |