| LD.ELF_SO(1) | General Commands Manual | LD.ELF_SO(1) | 
ld.elf_so —
ld.elf_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 information stored in data
  structures within the binary (see
  elf(5)) and environment variables
  to determine which shared objects are needed. These shared objects are loaded
  at a convenient virtual address using the
  mmap(2) system call. After all
  shared objects have been successfully loaded,
  ld.elf_so proceeds to resolve external references from
  both the main program and all objects loaded. Once all required references are
  resolved control is passed to the program via its entry point.
ld.elf_so
  is loaded is also supplied.
DT_NEEDED entry within the dynamic
  section. Each DT_NEEDED entry refers to a filename
  string of the shared object that is to be searched for.
The linker will search for libraries in three lists of paths:
The use of ld.so.conf should be avoided as the setting of a global search path can present a security risk.
DT_RPATH and DT_RUNPATH
      entries in the dynamic section. This is defined at shared object link
      time.Dynamic loading via
    dlopen(3) uses the
    DT_RPATH and DT_RUNPATH
    entries of the main binary, independently of which object the call came
    from.
ld.elf_so will expand the following
    variables if present in the paths:
kern.ostype
      sysctl(3).kern.osrelease
      sysctl(3).hw.machine_arch
      sysctl(3).Both ${VARIABLE} and
    $VARIABLE are recognized.
The filename string can be considered free form, however, it will almost always take the form lib<name>.so.<number>, where name specifies the ‘library’ name and number is conceptually the library's major version number.
This name and another of the form lib<name>.so are normally symbolic links to the real shared object which has a filename of the form lib<name>.so.<major>.<minor>[.<teeny>]. This naming convention allows a versioning scheme similar to a.out(5).
ld.elf_so will perform all necessary relocations
  immediately except for relocations relating to the Procedure Linkage Table
  (PLT). The PLT is used as an indirection method for procedure calls to
  globally defined functions. It allows, through the use of intermediate code,
  the delayed binding of a call to a globally defined function to be performed
  at procedure call time. This ‘lazy’ method is the default (see
  LD_BIND_NOW).
The DT_INIT and
    DT_FINI entries in the dynamic section specify the
    addresses of the initialization and termination functions, respectively, for
    the shared object. ld.elf_so arranges for each
    initialization function to be called before control is passed to the program
    and for the termination functions to be called by using
    atexit(3).
This mechanism is exploited by the system-supplied constructor initialization and destructor code located in /usr/lib/crtbeginS.o and /usr/lib/crtendS.o. These files are automatically included by cc(1) and c++(1) in the list of object-code files passed to ld(1) when building a shared C or C++ object.
ld.elf_so.
LD_LIBRARY_PATHLD_PRELOADLD_BIND_NOWLD_DEBUGld.elf_so was compiled with
      debugging support (-DDEBUG).The path expansion variables first appeared in Solaris 10, and in NetBSD 5.0.
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.
| April 15, 2019 | NetBSD 9.4 |