Provided by: manpages_6.03-1_all bug

NAME

       ld.so, ld-linux.so - dynamic linker/loader

SYNOPSIS

       The dynamic linker can be run either indirectly by running some dynamically linked program
       or shared object (in which case no command-line options  to  the  dynamic  linker  can  be
       passed  and, in the ELF case, the dynamic linker which is stored in the .interp section of
       the program is executed) or directly by running:

       /lib/ld-linux.so.*  [OPTIONS] [PROGRAM [ARGUMENTS]]

DESCRIPTION

       The programs ld.so and ld-linux.so* find and load the shared  objects  (shared  libraries)
       needed by a program, prepare the program to run, and then run it.

       Linux binaries require dynamic linking (linking at run time) unless the -static option was
       given to ld(1) during compilation.

       The program ld.so handles a.out binaries, a binary format  used  long  ago.   The  program
       ld-linux.so*   (/lib/ld-linux.so.1  for  libc5,  /lib/ld-linux.so.2  for  glibc2)  handles
       binaries that are in the more modern ELF format.  Both programs have  the  same  behavior,
       and use the same support files and programs (ldd(1), ldconfig(8), and /etc/ld.so.conf).

       When  resolving  shared  object  dependencies,  the  dynamic  linker  first  inspects each
       dependency string to see if it contains a  slash  (this  can  occur  if  a  shared  object
       pathname  containing  slashes  was specified at link time).  If a slash is found, then the
       dependency string is interpreted as a (relative or  absolute)  pathname,  and  the  shared
       object is loaded using that pathname.

       If  a  shared  object  dependency does not contain a slash, then it is searched for in the
       following order:

       (1)  Using the directories specified in the DT_RPATH  dynamic  section  attribute  of  the
            binary  if  present  and  DT_RUNPATH  attribute  does  not exist.  Use of DT_RPATH is
            deprecated.

       (2)  Using the environment variable LD_LIBRARY_PATH, unless the executable is being run in
            secure-execution mode (see below), in which case this variable is ignored.

       (3)  Using  the  directories  specified in the DT_RUNPATH dynamic section attribute of the
            binary if present.  Such directories are searched only to find those objects required
            by  DT_NEEDED  (direct  dependencies)  entries  and  do  not  apply to those objects'
            children, which must themselves have their own DT_RUNPATH entries.   This  is  unlike
            DT_RPATH, which is applied to searches for all children in the dependency tree.

       (4)  From  the  cache  file  /etc/ld.so.cache, which contains a compiled list of candidate
            shared objects previously found in the augmented  library  path.   If,  however,  the
            binary  was  linked with the -z nodeflib linker option, shared objects in the default
            paths are skipped.  Shared objects installed in hardware capability directories  (see
            below) are preferred to other shared objects.

       (5)  In  the  default  path  /lib,  and then /usr/lib.  (On some 64-bit architectures, the
            default paths for 64-bit shared objects are /lib64, and  then  /usr/lib64.)   If  the
            binary was linked with the -z nodeflib linker option, this step is skipped.

   Dynamic string tokens
       In several places, the dynamic linker expands dynamic string tokens:

       •  In the environment variables LD_LIBRARY_PATH, LD_PRELOAD, and LD_AUDIT,

       •  inside  the  values  of  the  dynamic  section  tags  DT_NEEDED,  DT_RPATH, DT_RUNPATH,
          DT_AUDIT, and DT_DEPAUDIT of ELF binaries,

       •  in the arguments to  the  ld.so  command  line  options  --audit,  --library-path,  and
          --preload (see below), and

       •  in the filename arguments to the dlopen(3) and dlmopen(3) functions.

       The substituted tokens are as follows:

       $ORIGIN (or equivalently ${ORIGIN})
              This  expands  to  the directory containing the program or shared object.  Thus, an
              application located in somedir/app could be compiled with

                  gcc -Wl,-rpath,'$ORIGIN/../lib'

              so that it finds an associated shared object in somedir/lib no matter where somedir
              is located in the directory hierarchy.  This facilitates the creation of "turn-key"
              applications that do not need to be installed into  special  directories,  but  can
              instead be unpacked into any directory and still find their own shared objects.

       $LIB (or equivalently ${LIB})
              This  expands  to  lib  or lib64 depending on the architecture (e.g., on x86-64, it
              expands to lib64 and on x86-32, it expands to lib).

       $PLATFORM (or equivalently ${PLATFORM})
              This expands to a string corresponding to the processor type  of  the  host  system
              (e.g.,  "x86_64").   On  some  architectures,  the  Linux  kernel doesn't provide a
              platform string to the dynamic linker.  The value of this string is taken from  the
              AT_PLATFORM value in the auxiliary vector (see getauxval(3)).

       Note  that  the dynamic string tokens have to be quoted properly when set from a shell, to
       prevent their expansion as shell or environment variables.

OPTIONS

       --argv0 string (since glibc 2.33)
              Set argv[0] to the value string before running the program.

       --audit list
              Use objects named in list as auditors.   The  objects  in  list  are  delimited  by
              colons.

       --inhibit-cache
              Do not use /etc/ld.so.cache.

       --library-path path
              Use  path instead of LD_LIBRARY_PATH environment variable setting (see below).  The
              names ORIGIN,  LIB,  and  PLATFORM  are  interpreted  as  for  the  LD_LIBRARY_PATH
              environment variable.

       --inhibit-rpath list
              Ignore  RPATH  and  RUNPATH  information  in  object names in list.  This option is
              ignored when running in secure-execution mode (see below).  The objects in list are
              delimited by colons or spaces.

       --list List all dependencies and how they are resolved.

       --list-tunables (since glibc 2.33)
              Print  the  names  and  values  of all tunables, along with the minimum and maximum
              allowed values.

       --preload list (since glibc 2.30)
              Preload the objects specified in list.  The objects in list are delimited by colons
              or  spaces.   The  objects  are  preloaded  as  explained in the description of the
              LD_PRELOAD environment variable below.

              By contrast with LD_PRELOAD,  the  --preload  option  provides  a  way  to  perform
              preloading  for  a  single executable without affecting preloading performed in any
              child process that executes a new program.

       --verify
              Verify that program is dynamically linked and this dynamic linker can handle it.

ENVIRONMENT

       Various environment variables influence the operation of the dynamic linker.

   Secure-execution mode
       For security reasons, if the dynamic linker determines that a  binary  should  be  run  in
       secure-execution  mode,  the effects of some environment variables are voided or modified,
       and furthermore those environment variables are stripped from the environment, so that the
       program does not even see the definitions.  Some of these environment variables affect the
       operation of the dynamic linker  itself,  and  are  described  below.   Other  environment
       variables  treated in this way include: GCONV_PATH, GETCONF_DIR, HOSTALIASES, LOCALDOMAIN,
       LOCPATH, MALLOC_TRACE,  NIS_PATH,  NLSPATH,  RESOLV_HOST_CONF,  RES_OPTIONS,  TMPDIR,  and
       TZDIR.

       A  binary  is  executed  in  secure-execution mode if the AT_SECURE entry in the auxiliary
       vector (see getauxval(3)) has a nonzero value.  This entry may have a  nonzero  value  for
       various reasons, including:

       •  The  process's  real and effective user IDs differ, or the real and effective group IDs
          differ.  This typically occurs as a result of executing a set-user-ID  or  set-group-ID
          program.

       •  A  process with a non-root user ID executed a binary that conferred capabilities to the
          process.

       •  A nonzero value may have been set by a Linux Security Module.

   Environment variables
       Among the more important environment variables are the following:

       LD_ASSUME_KERNEL (since glibc 2.2.3)
              Each shared object can inform the dynamic linker of the minimum kernel ABI  version
              that  it  requires.   (This  requirement  is encoded in an ELF note section that is
              viewable via readelf -n as a section labeled NT_GNU_ABI_TAG.)   At  run  time,  the
              dynamic  linker  determines  the  ABI version of the running kernel and will reject
              loading shared objects that specify minimum  ABI  versions  that  exceed  that  ABI
              version.

              LD_ASSUME_KERNEL  can  be  used  to  cause  the dynamic linker to assume that it is
              running on a system  with  a  different  kernel  ABI  version.   For  example,  the
              following  command  line causes the dynamic linker to assume it is running on Linux
              2.2.5 when loading the shared objects required by myprog:

                  $ LD_ASSUME_KERNEL=2.2.5 ./myprog

              On systems that  provide  multiple  versions  of  a  shared  object  (in  different
              directories  in  the  search  path)  that have different minimum kernel ABI version
              requirements, LD_ASSUME_KERNEL can be used to select the version of the object that
              is used (dependent on the directory search order).

              Historically,  the  most common use of the LD_ASSUME_KERNEL feature was to manually
              select the older LinuxThreads POSIX threads implementation on systems that provided
              both  LinuxThreads  and  NPTL  (which  latter  was  typically  the  default on such
              systems); see pthreads(7).

       LD_BIND_NOW (since glibc 2.1.1)
              If set to a nonempty string, causes the dynamic linker to resolve  all  symbols  at
              program  startup  instead  of  deferring function call resolution to the point when
              they are first referenced.  This is useful when using a debugger.

       LD_LIBRARY_PATH
              A list of directories in which to search for ELF libraries at execution time.   The
              items  in  the  list  are separated by either colons or semicolons, and there is no
              support for escaping either separator.  A zero-length directory name indicates  the
              current working directory.

              This variable is ignored in secure-execution mode.

              Within  the  pathnames specified in LD_LIBRARY_PATH, the dynamic linker expands the
              tokens $ORIGIN, $LIB, and $PLATFORM (or the versions using curly braces around  the
              names)  as  described  above  in  Dynamic  string  tokens.   Thus, for example, the
              following would cause a library to be searched for  in  either  the  lib  or  lib64
              subdirectory below the directory containing the program to be executed:

                  $ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog

              (Note  the  use  of  single  quotes, which prevent expansion of $ORIGIN and $LIB as
              shell variables!)

       LD_PRELOAD
              A list of additional, user-specified, ELF shared objects to be  loaded  before  all
              others.  This feature can be used to selectively override functions in other shared
              objects.

              The items of the list can be separated by spaces or colons, and there is no support
              for  escaping either separator.  The objects are searched for using the rules given
              under DESCRIPTION.  Objects are searched for and added to the link map in the left-
              to-right order specified in the list.

              In  secure-execution  mode,  preload  pathnames  containing  slashes  are  ignored.
              Furthermore, shared objects are preloaded only from the standard search directories
              and only if they have set-user-ID mode bit enabled (which is not typical).

              Within  the  names specified in the LD_PRELOAD list, the dynamic linker understands
              the tokens $ORIGIN, $LIB, and $PLATFORM (or the versions using curly braces  around
              the  names)  as described above in Dynamic string tokens.  (See also the discussion
              of quoting under the description of LD_LIBRARY_PATH.)

              There are various methods of specifying libraries to be preloaded,  and  these  are
              handled in the following order:

              (1)  The LD_PRELOAD environment variable.

              (2)  The --preload command-line option when invoking the dynamic linker directly.

              (3)  The /etc/ld.so.preload file (described below).

       LD_TRACE_LOADED_OBJECTS
              If  set  (to any value), causes the program to list its dynamic dependencies, as if
              run by ldd(1), instead of running normally.

       Then there are lots of more or less obscure variables, many obsolete or only for  internal
       use.

       LD_AUDIT (since glibc 2.4)
              A  list  of  user-specified, ELF shared objects to be loaded before all others in a
              separate linker namespace (i.e., one that does not intrude upon the  normal  symbol
              bindings  that  would  occur in the process) These objects can be used to audit the
              operation of the dynamic linker.  The items in the list  are  colon-separated,  and
              there is no support for escaping the separator.

              LD_AUDIT is ignored in secure-execution mode.

              The  dynamic  linker  will  notify  the  audit shared objects at so-called auditing
              checkpoints—for example, loading a  new  shared  object,  resolving  a  symbol,  or
              calling  a  symbol  from  another  shared object—by calling an appropriate function
              within the audit shared object.  For  details,  see  rtld-audit(7).   The  auditing
              interface  is largely compatible with that provided on Solaris, as described in its
              Linker and Libraries Guide, in the chapter Runtime Linker Auditing Interface.

              Within the names specified in the LD_AUDIT list, the dynamic linker understands the
              tokens  $ORIGIN, $LIB, and $PLATFORM (or the versions using curly braces around the
              names) as described above in Dynamic string tokens.  (See also  the  discussion  of
              quoting under the description of LD_LIBRARY_PATH.)

              Since  glibc  2.13,  in secure-execution mode, names in the audit list that contain
              slashes are ignored, and only shared objects in  the  standard  search  directories
              that have the set-user-ID mode bit enabled are loaded.

       LD_BIND_NOT (since glibc 2.1.95)
              If  this  environment  variable  is set to a nonempty string, do not update the GOT
              (global offset table) and PLT (procedure linkage table) after resolving a  function
              symbol.   By  combining the use of this variable with LD_DEBUG (with the categories
              bindings and symbols), one can observe all run-time function bindings.

       LD_DEBUG (since glibc 2.1)
              Output verbose debugging information about operation of the  dynamic  linker.   The
              content  of  this variable is one of more of the following categories, separated by
              colons, commas, or (if the value is quoted) spaces:

              help        Specifying help in  the  value  of  this  variable  does  not  run  the
                          specified  program,  and displays a help message about which categories
                          can be specified in this environment variable.

              all         Print all debugging information  (except  statistics  and  unused;  see
                          below).

              bindings    Display information about which definition each symbol is bound to.

              files       Display progress for input file.

              libs        Display library search paths.

              reloc       Display relocation processing.

              scopes      Display scope information.

              statistics  Display relocation statistics.

              symbols     Display search paths for each symbol look-up.

              unused      Determine unused DSOs.

              versions    Display version dependencies.

              Since  glibc  2.3.4,  LD_DEBUG is ignored in secure-execution mode, unless the file
              /etc/suid-debug exists (the content of the file is irrelevant).

       LD_DEBUG_OUTPUT (since glibc 2.1)
              By default, LD_DEBUG output is written to standard error.   If  LD_DEBUG_OUTPUT  is
              defined,  then  output  is written to the pathname specified by its value, with the
              suffix "." (dot) followed by the process ID appended to the pathname.

              LD_DEBUG_OUTPUT is ignored in secure-execution mode.

       LD_DYNAMIC_WEAK (since glibc 2.1.91)
              By default, when searching shared libraries to  resolve  a  symbol  reference,  the
              dynamic linker will resolve to the first definition it finds.

              Old glibc versions (before glibc 2.2), provided a different behavior: if the linker
              found a symbol that was weak, it would remember that symbol and keep  searching  in
              the  remaining  shared  libraries.  If it subsequently found a strong definition of
              the same symbol, then it would instead use that definition.  (If no further  symbol
              was  found,  then  the  dynamic  linker would use the weak symbol that it initially
              found.)

              The old glibc behavior was nonstandard.  (Standard practice is that the distinction
              between  weak  and strong symbols should have effect only at static link time.)  In
              glibc 2.2, the dynamic linker was modified to provide the current  behavior  (which
              was the behavior that was provided by most other implementations at that time).

              Defining the LD_DYNAMIC_WEAK environment variable (with any value) provides the old
              (nonstandard) glibc behavior, whereby a weak symbol in one shared  library  may  be
              overridden  by  a  strong symbol subsequently discovered in another shared library.
              (Note that even when this variable is set, a strong symbol in a shared library will
              not override a weak definition of the same symbol in the main program.)

              Since glibc 2.3.4, LD_DYNAMIC_WEAK is ignored in secure-execution mode.

       LD_HWCAP_MASK (since glibc 2.1)
              Mask for hardware capabilities.

       LD_ORIGIN_PATH (since glibc 2.1)
              Path where the binary is found.

              Since glibc 2.4, LD_ORIGIN_PATH is ignored in secure-execution mode.

       LD_POINTER_GUARD (from glibc 2.4 to glibc 2.22)
              Set  to  0  to disable pointer guarding.  Any other value enables pointer guarding,
              which is also the default.  Pointer guarding is a security mechanism  whereby  some
              pointers  to  code  stored  in  writable  program memory (return addresses saved by
              setjmp(3) or function pointers used by various glibc internals) are  mangled  semi-
              randomly  to  make it more difficult for an attacker to hijack the pointers for use
              in the event of a buffer overrun  or  stack-smashing  attack.   Since  glibc  2.23,
              LD_POINTER_GUARD  can  no  longer be used to disable pointer guarding, which is now
              always enabled.

       LD_PROFILE (since glibc 2.1)
              The name of a (single) shared object to be profiled, specified either as a pathname
              or   a   soname.   Profiling  output  is  appended  to  the  file  whose  name  is:
              "$LD_PROFILE_OUTPUT/$LD_PROFILE.profile".

              Since glibc 2.2.5, LD_PROFILE is ignored in secure-execution mode.

       LD_PROFILE_OUTPUT (since glibc 2.1)
              Directory where LD_PROFILE output should be  written.   If  this  variable  is  not
              defined, or is defined as an empty string, then the default is /var/tmp.

              LD_PROFILE_OUTPUT  is  ignored  in  secure-execution  mode; instead /var/profile is
              always used.  (This detail is relevant only before  glibc  2.2.5,  since  in  later
              glibc versions, LD_PROFILE is also ignored in secure-execution mode.)

       LD_SHOW_AUXV (since glibc 2.1)
              If  this environment variable is defined (with any value), show the auxiliary array
              passed up from the kernel (see also getauxval(3)).

              Since glibc 2.3.4, LD_SHOW_AUXV is ignored in secure-execution mode.

       LD_TRACE_PRELINKING (since glibc 2.4)
              If this environment variable is defined, trace prelinking of the object whose  name
              is assigned to this environment variable.  (Use ldd(1) to get a list of the objects
              that might be traced.)  If the object name is not recognized, then  all  prelinking
              activity is traced.

       LD_USE_LOAD_BIAS (since glibc 2.3.3)
              By  default  (i.e.,  if  this  variable  is not defined), executables and prelinked
              shared objects will honor base addresses of  their  dependent  shared  objects  and
              (nonprelinked)  position-independent  executables  (PIEs)  and other shared objects
              will not honor them.  If  LD_USE_LOAD_BIAS  is  defined  with  the  value  1,  both
              executables and PIEs will honor the base addresses.  If LD_USE_LOAD_BIAS is defined
              with the value 0, neither executables nor PIEs will honor the base addresses.

              Since glibc 2.3.3, this variable is ignored in secure-execution mode.

       LD_VERBOSE (since glibc 2.1)
              If set to a nonempty string, output symbol versioning information about the program
              if the LD_TRACE_LOADED_OBJECTS environment variable has been set.

       LD_WARN (since glibc 2.1.3)
              If set to a nonempty string, warn about unresolved symbols.

       LD_PREFER_MAP_32BIT_EXEC (x86-64 only; since glibc 2.23)
              According   to  the  Intel  Silvermont  software  optimization  guide,  for  64-bit
              applications, branch prediction performance can be  negatively  impacted  when  the
              target  of  a  branch  is more than 4 GB away from the branch.  If this environment
              variable is set (to any value), the dynamic linker will first try to map executable
              pages  using the mmap(2) MAP_32BIT flag, and fall back to mapping without that flag
              if that attempt fails.  NB: MAP_32BIT will map to the low 2 GB (not  4 GB)  of  the
              address space.

              Because  MAP_32BIT  reduces  the  address  range available for address space layout
              randomization  (ASLR),  LD_PREFER_MAP_32BIT_EXEC  is  always  disabled  in  secure-
              execution mode.

FILES

       /lib/ld.so
              a.out dynamic linker/loader

       /lib/ld-linux.so.{1,2}
              ELF dynamic linker/loader

       /etc/ld.so.cache
              File  containing  a  compiled  list  of  directories  in which to search for shared
              objects and an ordered list of candidate shared objects.  See ldconfig(8).

       /etc/ld.so.preload
              File containing a whitespace-separated list of ELF  shared  objects  to  be  loaded
              before  the  program.   See the discussion of LD_PRELOAD above.  If both LD_PRELOAD
              and /etc/ld.so.preload are employed, the  libraries  specified  by  LD_PRELOAD  are
              preloaded   first.   /etc/ld.so.preload  has  a  system-wide  effect,  causing  the
              specified libraries to be preloaded for all  programs  that  are  executed  on  the
              system.   (This  is  usually  undesirable,  and  is  typically  employed only as an
              emergency  remedy,  for  example,  as  a  temporary   workaround   to   a   library
              misconfiguration issue.)

       lib*.so*
              shared objects

NOTES

   Hardware capabilities
       Some  shared  objects are compiled using hardware-specific instructions which do not exist
       on every CPU.  Such objects should be installed in  directories  whose  names  define  the
       required  hardware  capabilities, such as /usr/lib/sse2/.  The dynamic linker checks these
       directories against the hardware of the machine and selects the most suitable version of a
       given  shared  object.   Hardware  capability  directories  can be cascaded to combine CPU
       features.  The list of supported hardware  capability  names  depends  on  the  CPU.   The
       following names are currently recognized:

       Alpha  ev4, ev5, ev56, ev6, ev67

       MIPS   loongson2e, loongson2f, octeon, octeon2

       PowerPC
              4xxmac,  altivec,  arch_2_05,  arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle,
              fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+,  power6x,  ppc32,  ppc601,
              ppc64, smt, spe, ucache, vsx

       SPARC  flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2

       s390   dfp,  eimm,  esan3,  etf3enh,  g5,  highgprs, hpage, ldisp, msa, stfle, z900, z990,
              z9-109, z10, zarch

       x86 (32-bit only)
              acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586,  i686,  mca,  mmx,
              mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm

SEE ALSO

       ld(1),  ldd(1),  pldd(1),  sprof(1),  dlopen(3),  getauxval(3),  elf(5),  capabilities(7),
       rtld-audit(7), ldconfig(8), sln(8)