LD.AOUT_SO(1) | General Commands Manual | LD.AOUT_SO(1) |
ld.aout_so
—
ld.aout_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 the data structures (see
link(5)) contained within
dynamically linked programs to determine which shared libraries are needed and
loads them at a convenient virtual address using the
mmap(2) system call.
After all shared libraries have been successfully loaded,
ld.aout_so
proceeds to resolve external references
from both the main program and all objects loaded. A mechanism is provided
for initialization routines to be called, on a per-object basis, giving a
shared object an opportunity to perform any extra set-up, before execution
of the program proper begins. ld.aout_so
looks for a
symbol named .init in each object's symbol table. If
present, this symbol is assumed to represent a C-function declared as
void
.init
(void), which is then
called. Similarly, a void
.fini
(void) function is called
just before an object is unloaded from the process address space as a result
of calling dlclose(3). Note
that while an object's .init is always called, whether the
object is loaded automatically at program startup or programmatically by
using dlopen(3), the
.fini function is called only on ‘last
dlclose(3)’.
This mechanism is exploited by the system-supplied C++ constructor initialization code located in /usr/lib/c++rt.o. This file should be included in the list of object-code files passed to ld(1) when building a shared C++ library.
ld.aout_so
is itself a shared object that
is initially loaded by the startup module crt0. Since
a.out(5) formats do not provide
easy access to the file header from within a running process,
crt0 uses the special symbol
_DYNAMIC to determine whether a program is in fact
dynamically linked or not. Whenever the linker
ld(1) has relocated this symbol to
a location other than 0, crt0 assumes the services of
ld.aout_so
are needed (see
link(5) for details).
crt0 passes control to rtld
's
entry point before the program's main
() routine is
called. Thus, ld.aout_so
can complete the
link-editing process before the dynamic program calls upon services of any
dynamic library.
To quickly locate the required shared objects in the filesystem,
ld.aout_so
may use a “hints” file,
prepared by the ldconfig(8)
utility, in which the full path specification of the shared objects can be
looked up by hashing on the 3-tuple ⟨library-name,
major-version-number, minor-version-number⟩.
ld.aout_so
recognizes a number of
environment variables that can be used to modify its behavior as
follows:
LD_LIBRARY_PATH
LD_PRELOAD
LD_WARN_NON_PURE_CODE
LD_SUPPRESS_WARNINGS
LD_TRACE_LOADED_OBJECTS
ld.aout_so
to exit after loading
the shared objects and printing a summary which includes the absolute
pathnames of all objects, to standard output.LD_TRACE_LOADED_OBJECTS_FMT1
LD_TRACE_LOADED_OBJECTS_FMT2
-f
option and allows
ldd(1) to be operated as a
filter more conveniently. The following conversions can be used:
LD_TRACE_LOADED_OBJECTS_PROGNAME
rtld
's
library search rules.Additionally, \n and \t are recognized and have their usual meaning.
LD_NO_INTERN_SEARCH
ld.aout_so
does not process any internal
search paths that were recorded in the executable.LD_NOSTD_PATH
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.
January 1, 2011 | NetBSD 9.4 |