| 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_PATHLD_PRELOADLD_WARN_NON_PURE_CODELD_SUPPRESS_WARNINGSLD_TRACE_LOADED_OBJECTSld.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_FMT1LD_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_PROGNAMErtld's
library search rules.Additionally, \n and \t are recognized and have their usual meaning.
LD_NO_INTERN_SEARCHld.aout_so does not process any internal
search paths that were recorded in the executable.LD_NOSTD_PATHLD_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 8.99 |