Provided by: manpages_6.8-2_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.

       (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 nodefaultlib  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 nodefaultlib 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.

       --glibc-hwcaps-mask list
              only search built-in subdirectories if in list.

       --glibc-hwcaps-prepend list
              Search glibc-hwcaps subdirectories in list.

       --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-diagnostics (since glibc 2.33)
              Print system diagnostic information in a  machine-readable  format,  such  as  some
              internal  loader  variables,  the  auxiliary  vector  (see  getauxval(3)),  and the
              environment variables.  On some architectures, the command might  print  additional
              information (like the cpu features used in GNU indirect function selection on x86).
              --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,
       LD_AUDIT,  LD_DEBUG,  LD_DEBUG_OUTPUT,  LD_DYNAMIC_WEAK,  LD_HWCAP_MASK,  LD_LIBRARY_PATH,
       LD_ORIGIN_PATH, LD_PRELOAD, LD_PROFILE, LD_SHOW_AUXV, 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 (from glibc 2.2.3 to glibc 2.36)
              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 (from glibc 2.1 to glibc 2.38)
              Mask  for  hardware capabilities.  Since glibc 2.26, the option might be ignored if
              glibc does not support tunables.

       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  uses a different default path 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.

       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 (from glibc 2.4 to glibc 2.35)
              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 (from glibc 2.3.3 to glibc 2.35)
              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

   Legacy Hardware capabilities (from glibc 2.5 to glibc 2.37)
       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

       The legacy hardware capabilities support has the drawback  that  each  new  feature  added
       grows  the  search  path exponentially, because it has to be added to every combination of
       the other existing features.

       For instance, on x86 32-bit, if the hardware supports i686 and sse2, the resulting  search
       path  will  be i686/sse2:i686:sse2:..  A new capability newcap will set the search path to
       newcap/i686/sse2:newcap/i686:newcap/sse2:newcap:i686/sse2:i686:sse2:.

   glibc Hardware capabilities (from glibc 2.33)
       glibc 2.33 added a new hardware capability scheme,
              where under each CPU architecture, certain levels can be defined, grouping  support
              for  certain features or special instructions.  Each architecture level has a fixed
              set of paths that it adds to the dynamic  linker  search  list,  depending  on  the
              hardware  of  the  machine.  Since each new architecture level is not combined with
              previously existing ones, the new scheme does not have the drawback of growing  the
              dynamic linker search list uncontrollably.

       For  instance,  on  x86  64-bit,  if  the  hardware supports x86_64-v3 (for instance Intel
       Haswell or AMD Excavator), the resulting search path will be glibc-hwcaps/x86-64-v3:glibc-
       hwcaps/x86-64-v2:.  The following paths are currently supported, in priority order.

       PowerPC (64-bit little-endian only)
              power10, power9

       s390 (64-bit only)
              z16, z15, z14, z13

       x86 (64-bit only)
              x86-64-v4, x86-64-v3, x86-64-v2

       glibc 2.37 removed support for the legacy hardware capabilities.

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)