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

     ld.so -- run-time link-editor

     ld.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)) con-
     tained 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.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.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 automati-
     cally 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 ini-
     tialization 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.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.so are needed (see link(5)
     for details).  crt0 passes control to rtld's entry point before the pro-
     gram's main() routine is called.  Thus, ld.so can complete the link-edit-
     ing process before the dynamic program calls upon services of any dynamic

     To quickly locate the required shared objects in the filesystem, ld.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-

     ld.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, overrid-
                              ing the default search path for shared

     LD_PRELOAD               A colon separated list of shared object file-
                              names 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-edit-
                              ing 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 satis-
                              factorily versioned library could not be found.

     LD_TRACE_LOADED_OBJECTS  When set, causes ld.so to exit after loading the
                              shared objects and printing a summary which
                              includes the absolute pathnames of all objects,
                              to standard output.


                              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 conversions
                              can be used:

                              %a    The main program's name (also known as

                              %A    The value of the environment variable

                              %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, \n and \t are recognized and have
                              their usual meaning.

     LD_NO_INTERN_SEARCH      When set, ld.so does not process any internal
                              search paths that were recorded in the exe-

     LD_NOSTD_PATH            When set, do not include a set of built-in stan-
                              dard directory paths for searching.  This might
                              be useful when running on a system with a com-
                              pletely non-standard filesystem layout.

     /var/run/ld.so.hints     library location hints built by ldconfig(8)

     ld(1), ld.elf_so(1), ld.so(1), link(5), ldconfig(8)

     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.

NetBSD 5.0.1                    March 24, 2000                    NetBSD 5.0.1

You can also request any man page by name and (optionally) by section:


Use the DEFAULT collection to view manual pages for third-party software.

©1994 Man-cgi 1.15, Panagiotis Christias
©1996-2018 Modified for NetBSD by Kimmo Suominen