| 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 9.4 |