Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

rtld(1) [netbsd man page]

LD.SO(1)						    BSD General Commands Manual 						  LD.SO(1)

NAME -- run-time link-editor DESCRIPTION is a self-contained, position independent program image providing run-time support for loading and link-editing shared objects into a process' address space. For the particular details, refer to ld.aout_so(1) or ld.elf_so(1), depending on the system's object file format. SEE ALSO
ld(1), ld.aout_so(1), ld.elf_so(1), a.out(5), elf(5), link(5), ldconfig(8) John R. Levine, Linkers and Loaders, Morgan Kaufmann, 1999. BSD
March 31, 2010 BSD

Check Out this Related Man Page

LD.AOUT_SO(1)						    BSD General Commands Manual 					     LD.AOUT_SO(1)

ld.aout_so -- run-time link-editor DESCRIPTION
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 programmat- ically 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 A colon separated list of directories, overriding the default search path for shared libraries. LD_PRELOAD A colon separated list of shared object filenames to be loaded after the main program but before its shared object dependencies. LD_WARN_NON_PURE_CODE When set, issue a warning whenever a link-editing operation requires modification of the text segment of some loaded object. This is usually indicative of an incorrectly built library. LD_SUPPRESS_WARNINGS When set, no warning messages of any kind are issued. Normally, a warning is given if satisfactorily versioned library could not be found. LD_TRACE_LOADED_OBJECTS When set, causes ld.aout_so to exit after loading the shared objects and printing a summary which includes the abso- lute pathnames of all objects, to standard output. LD_TRACE_LOADED_OBJECTS_FMT1 LD_TRACE_LOADED_OBJECTS_FMT2 When set, these variables are interpreted as format strings a la printf(3) to customize the trace output and are used by ldd(1)'s -f option and allows ldd(1) to be operated as a filter more conveniently. The following conver- sions can be used: %a The main program's name (also known as ``__progname''). %A The value of the environment variable LD_TRACE_LOADED_OBJECTS_PROGNAME %o The library name. %m The library's major version number. %n The library's minor version number. %p The full pathname as determined by rtld's library search rules. %x The library's load address. Additionally, and are recognized and have their usual meaning. LD_NO_INTERN_SEARCH When set, ld.aout_so does not process any internal search paths that were recorded in the executable. LD_NOSTD_PATH When set, do not include a set of built-in standard directory paths for searching. This might be useful when run- ning on a system with a completely non-standard filesystem layout. FILES
/var/run/ library location hints built by ldconfig(8) SEE ALSO
ld(1), ld.elf_so(1),, link(5), ldconfig(8) HISTORY
The shared library model employed first appeared in SunOS 4.0. SECURITY CONSIDERATIONS
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. BSD
January 1, 2011 BSD
Man Page