Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Apropos / Subsearch:
optional field

ldd(1)                           User Commands                          ldd(1)

       ldd - list dynamic dependencies of executable files or shared objects

       ldd [-d | -r]  [-c] [-e envar] [-f] [-i] [-L] [-l] [-s] [-U | -u]  [-v]

       The ldd utility lists the dynamic dependencies of executable  files  or
       shared  objects.  ldd uses the runtime linker, ld.so.1, to generate the
       diagnostics. The runtime linker takes the object  being  inspected  and
       prepares  the  object  as would occur in a running process. By default,
       ldd triggers the loading of any lazy dependencies.

       ldd lists the path names of all shared objects  that  would  be  loaded
       when  filename is loaded. ldd expects the shared objects that are being
       inspected to have execute permission. If a shared object does not  have
       execute  permission,  ldd issues a warning before attempting to process
       the file.

       ldd processes its input one file at a time. For each file, ldd performs
       one of the following:

         o  Lists the object dependencies if the dependencies exist.

         o  Succeeds quietly if dependencies do not exist.

         o  Prints an error message if processing fails.

       ldd  can  also  check  the  compatibility  of  filename with the shared
       objects filename uses. With each of the following options,  ldd  prints
       warnings  for  any  unresolved  symbol references that would occur when
       filename is loaded.

       -d       Check immediate references.

       -r       Check both immediate references and lazy references.

       Only one of the options -d or -r  can be specified  during  any  single
       invocation  of  ldd.  immediate  references are typically to data items
       used by the executable or shared object code. immediate references  are
       also  pointers  to  functions,  and even calls to functions made from a
       position dependent shared object. lazy references are  typically  calls
       to  global functions made from a position independent shared object, or
       calls to external functions made from an executable. For more  informa-
       tion  on  these  types  of  reference,  see ``When Relocations Are Per-
       formed'' in the Linker and Libraries Guide.  Object loading can also be
       affected  by  relocation  processing.  See Lazy Loading under USAGE for
       more details.

       ldd can also check dependency use. With each of the following  options,
       ldd  prints  warnings for any unreferenced, or unused dependencies that
       are loaded when filename is loaded. Only when  a  symbol  reference  is
       bound  to  a  dependency, is that dependency deemed used. These options
       are therefore only useful when symbol references are being checked.  If
       the -r option is not in effect, the -d option is enabled.

       A dependency that is defined by an object but is not bound to from that
       object is an unreferenced dependency. A dependency that is not bound to
       by any other object when filename is loaded is an unused object.

       -U       Displays  any  unreferenced,  or  unused  dependencies.  If an
                unreferenced dependency is  not  bound  to  by  other  objects
                loaded  with  filename,  the  dependency  is  also  flagged as
                unused. Cyclic dependencies that are not bound to from objects
                outside of the cycle are also deemed unreferenced.

       -u       Displays any unused objects.

       Only  one  of  the  options -U or -u can be specified during any single
       invocation of ldd, although -U is a superset of -u.  Objects  that  are
       found to be unreferenced, or unused when using the -r option, should be
       removed as dependencies.  These  objects  provide  no  references,  but
       result  in unnecessary overhead when filename is loaded. When using the
       -d option, any objects that are found to be unreferenced, or unused are
       not  immediately  required  when  filename is loaded. These objects are
       candidates for lazy loading. See Lazy  Loading  under  USAGE  for  more

       The  removal  of  unused dependencies reduces runtime-linking overhead.
       The removal of unreferenced dependencies reduces runtime-linking  over-
       head to a lesser degree. However, the removal of unreferenced dependen-
       cies guards against a dependency being unused when combined  with  dif-
       ferent objects, or as the other object dependencies evolve.

       The following additional options are supported:

       -c              Disables  any  configuration  file  use.  Configuration
                       files can be employed to alter  default  search  paths,
                       and   provide   alternative  object  dependencies.  See

       -e envar        Sets the environment variable  envar.  This  option  is
                       useful  for  experimenting  with  environment variables
                       that are recognized by the  runtime  linker,  that  can
                       adversely affect ldd.

       -f              Forces  ldd to check for an executable file that is not
                       secure. When ldd is invoked by a superuser, by  default
                       ldd does not process any executable that is not secure.
                       An executable is not considered secure  if  the  inter-
                       preter  that  the  executable specifies does not reside
                       under /lib, /usr/lib or /etc/lib. An executable is also
                       not  considered  secure  if  the  interpreter cannot be
                       determined. See Security under USAGE.

       -i              Displays the order of execution of initialization  sec-
                       tions.  The order that is discovered can be affected by
                       use of the -d or -r options. See  Initialization  Order
                       under USAGE.

       -L              Enables  lazy loading. Lazy loading is the default mode
                       of operation when the object under inspection is loaded
                       as  part of a process. In this case, any lazy dependen-
                       cies, or filters, are only loaded into the process when
                       reference  is  made  to a symbol that is defined within
                       the lazy object. The -d or -r  options,  together  with
                       the -L option, can be used to inspect the dependencies,
                       and their order of loading as would occur in a  running

       -l              Forces  the immediate processing of any filters so that
                       all filtees, and their dependencies,  are  listed.  The
                       immediate processing of filters is now the default mode
                       of operation for ldd. However, under this  default  any
                       auxiliary  filtees  that  cannot  be found are silently
                       ignored. Under the -l option, missing auxiliary filtees
                       generate an error message.

       -s              Displays  the  search path used to locate shared object

       -v              Displays all  dependency  relationships  incurred  when
                       processing  filename.  This  option  also  displays any
                       dependency version requirements. See pvs(1).

       A superuser should use the -f option only if the executable to be exam-
       ined is known to be trustworthy. The use of -f on an untrustworthy exe-
       cutable while superuser can compromise system security. If an  executa-
       bles  trustworthyness is unknown, a superuser should temporarily become
       a regular user. Then invoke ldd as this regular user.

       Untrustworthy objects can be safely  examined  with  dump(1)  and  with
       mdb(1),  as  long as the :r subcommand is not used. In addition, a non-
       superuser can use either the :r subcommand of mdb, or truss(1) to exam-
       ine an untrustworthy executable without too much risk of compromise. To
       minimize risk when using ldd, adb :r, or truss on an untrustworthy exe-
       cutable, use the UID "nobody".

   Lazy Loading
       Lazy  loading  can  be applied directly by specified lazy dependencies.
       See the -z lazyload option of ld(1). Lazy loading can also  be  applied
       indirectly  through  filters. See the -f option and -F option of ld(1).
       Objects that employ lazy loading techniques can  experience  variations
       in  ldd  output due to the options used. If an object expresses all its
       dependencies as lazy, the default operation of ldd lists all  dependen-
       cies  in  the  order  in  which  the  dependencies are recorded in that

       example% ldd main
               libelf.so.1 =>   /lib/libelf.so.1
               libnsl.so.1 =>   /lib/libnsl.so.1
               libc.so.1 =>     /lib/libc.so.1

       The lazy loading behavior that occurs when this object is used at  run-
       time  can  be enabled using the -L option. In this mode, lazy dependen-
       cies are loaded when reference is made to  a  symbol  that  is  defined
       within  the lazy object. Therefore, combining the -L option with use of
       the -d and -r options reveals the dependencies that are needed to  sat-
       isfy the immediate, and lazy references respectively:

       example% ldd -L main
       example% ldd -d main
               libc.so.1 =>       /lib/libc.so.1
       example% ldd -r main
               libc.so.1 =>       /lib/libc.so.1
               libelf.so.1 =>   /lib/libelf.so.1

       Notice  that  in  this  example, the order of the dependencies that are
       listed is not the same as displayed from ldd with no options. Even with
       the  -r  option,  the lazy reference to dependencies might not occur in
       the same order as would occur in a running program.

       Observing lazy loading can also reveal objects that are not required to
       satisfy  any  references.  These objects, in this example, libnsl.so.1,
       are candidates for removal from the link-line used to build the  object
       being inspected.

   Initialization Order
       Objects that do not explicitly define their required dependencies might
       observe variations in the initialization section order displayed by ldd
       due  to  the  options  used.  For  example,  a simple application might

       example% ldd -i main
               libA.so.1 =>     ./libA.so.1
               libc.so.1 =>     /lib/libc.so.1
               libB.so.1 =>     ./libB.so.1

           init object=./libB.so.1
           init object=./libA.so.1
           init object=/lib/libc.so.1

       whereas, when relocations are applied, the initialization section order

       example% ldd -ir main

           init object=/lib/libc.so.1
           init object=./libB.so.1
           init object=./libA.so.1

       In   this   case,   libB.so.1   makes   reference   to  a  function  in
       /usr/lib/libc.so.1. However, libB.so.1 has no  explicit  dependency  on
       this  library.   Only  after a relocation is discovered is a dependency
       then established. This implicit dependency affects  the  initialization
       section order.

       Typically,  the initialization section order established when an appli-
       cation is executed, is equivalent to ldd with the -d option. The  opti-
       mum  order  can be obtained if all objects fully define their dependen-
       cies. Use of the  ld(1)  options  -zdefs  and  -zignore  when  building
       dynamic objects is recommended.

       Cyclic  dependencies can result when one or more dynamic objects refer-
       ence each other. Cyclic dependencies should be  avoided,  as  a  unique
       initialization  sort  order  for  these  dependencies can not be estab-

       Users that prefer a more static analysis of object  files  can  inspect
       dependencies using tools such as dump(1) and elfdump(1).

       /usr/lib/lddstub        Fake  32-bit  executable  loaded  to  check the
                               dependencies of shared objects.

       /usr/lib/64/lddstub     Fake 64-bit  executable  loaded  to  check  the
                               dependencies of shared objects.

       See attributes(5) for descriptions of the following attributes:

       tab()     allbox;     cw(2.750000i)|    cw(2.750000i)    lw(2.750000i)|
       lw(2.750000i).  ATTRIBUTE TYPEATTRIBUTE VALUE AvailabilitySUNWtoo

       mdb(1),  crle(1),  dump(1),  elfdump(1),  ld(1),  ld.so.1(1),   pvs(1),
       truss(1),  dlopen(3C), attributes(5)

       Linker and Libraries Guide

       ldd  prints  the  record  of  shared  object  path names to stdout. The
       optional list of symbol resolution problems is printed  to  stderr.  If
       filename  is  not an executable file or a shared object, or if filename
       cannot be opened for reading, a non-zero exit status is returned.

       ldd does not list shared objects explicitly attached using dlopen(3C).

       Use of the -d or -r option with  shared  objects  can  give  misleading
       results.  ldd  does a "worst case" analysis of the shared objects. How-
       ever, in practice, the symbols reported as unresolved might be resolved
       by the executable file referencing the shared object. The runtime link-
       ers preloading mechanism can be employed to  add  dependencies  to  the
       object being inspected. See LD_PRELOAD.

       ldd  uses  the  same  algorithm  as the runtime linker to locate shared

SunOS 5.10                        14 Apr 2004                           ldd(1)