LD.AOUT_SO(1) | General Commands Manual | LD.AOUT_SO(1) |
ld.aout_so
—
run-time link-editor
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
The shared library model employed first appeared in SunOS 4.0.
The environment variables 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 10.99 |