ldd - list  dynamic  dependencies  of  executable  files  or
     shared objects


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


     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,  since  it  takes  the
     object being inspected and prepares it as it would in a run-
     ning process. By default, ldd triggers the  loading  of  any
     lazy dependencies.

     ldd lists the path names of all shared objects that will  be
     loaded  when  filename is loaded. ldd expects shared objects
     to have execute permission. If this is  not  the  case,  ldd
     will issue a warning before attempting to process the file.

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

        o  Lists the object dependencies if they 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 it 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 and lazy references.

     Only one of the above options can be  specified  during  any
     single invocation of ldd. immediate references are typically
     to data items used by the executable or shared object  code,
     pointers to functions, and even calls to functions made from
     a position dependent shared object. lazy references are typ-
     ically  calls  to  global  functions  made  from  a position
     independent shared object, or calls  to  external  functions
     made from an executable. For more information on these types
     of reference, see ``When Relocations Are Performed'' 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  follow-
     ing  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 depen-
     dency 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, it is  also  flagged  as
           unused. Cyclic dependencies that are not bound to from
           objects outside of the cycle are also deemed  unrefer-

     -u    Displays any unused objects.

     Only one of the above options 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. They
     provide no references but  result  in  unnecessary  overhead
     when  filename  is  loaded.  Objects  that  are  found to be
     unreferenced or unused when using  the  -d  option  are  not
     immediately required when filename is loaded, and are there-
     fore candidates for lazy loading.  See  Lazy  Loading  under
     USAGE for more details.

     The removal of unused dependencies reduces  runtime  linking
     overhead.  The  removal of unreferenced dependencies reduces
     runtime linking overhead to a lesser degree, but also guards
     against a dependency becoming 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  may  be employed to alter default search paths,
           provide a directory  cache,  and  provide  alternative
           object dependencies. See crle(1).

     -e envar
           Sets the environment variable envar.  This  option  is
           useful  for experimenting with runtime linker environ-
           ment variables that can adversely affect ldd itself.

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

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

     -L    Enables lazy loading. This  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, may be used to inspect the  depen-
           dencies and their order of loading since it will occur
           in a running process.

     -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 auxili-
           ary 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 examined is known to be trustworthy, because use of -f
     on an untrustworthy executable while superuser may  comprom-
     ise  system  security.  If  it is unknown whether or not the
     executable to be examined is trustworthy, a superuser should
     temporarily  become  a  regular  user and invoke ldd as that
     regular user.

     Untrustworthy objects can be safely  examined  with  dump(1)
     and  with  adb(1), as long as the :r subcommand is not used.
     In addition, a non-superuser can use either the  :r  subcom-
     mand  of adb or truss(1) to examine an untrustworthy execut-
     able without too much risk of compromise. To  minimize  risk
     when using ldd, adb :r, or truss on an untrustworthy execut-
     able, use the user id "nobody".

  Lazy Loading
     Objects that employ lazy loading techniques, either  through
     directly  specified  lazy  dependencies (see the -z lazyload
     option of ld(1)), or through filters  (see  the  -f  and  -F
     options  of  ld(1)), may experience variations in ldd output
     due to the options they use. If an object expresses all  its
     dependencies as lazy, the default operation of ldd will list
     all dependencies in the order in which they are recorded  in
     that object:

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

     The lazy loading behavior that occurs when  this  object  is
     used  at runtime may be enabled using the -L option. In this
     mode, lazy dependencies 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
     will reveal the dependencies needed to satisfy the immediate
     and lazy references respectively:

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

     Notice that in this example, the order of  the  dependencies
     listed  is  not  the  same  as  displayed  from  ldd with no
     options, and even with the -r option, the lazy reference  to
     dependencies may not occur in the same order as it will in a
     running program.

     Observing lazy loading may 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  depen-
     dencies may observe variations in the initialization section
     order displayed by ldd due to  the  options  they  use.  For
     example, a simple application may reveal:

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

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

     whereas, when relocations are  applied,  the  initialization
     section order is:

     example% ldd -ir main

         init object=/usr/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,  it has no explicit dependency
     on this library. Only after a relocation is discovered is  a
     dependency  established, which in turn affects the initiali-
     zation section sort order.

     Typically, the initialization section sort order established
     when  an  application  is executed is equivalent to ldd with
     the -d option. The optimum order  can  be  obtained  if  all
     objects  fully  define  their dependencies. Use of the ld(1)
     options -zdefs and -zignore when building dynamic objects is

     Cyclic dependencies may result  when  one  or  more  dynamic
     objects  reference each other. Cyclic dependencies should be
     avoided, as a unique initialization  sort  order  for  these
     dependencies can not be established.

     Users that prefer a more static analysis of object files may
     inspect  dependencies  using  tools such as dump(1) and elf-


           Fake 32-bit executable loaded to check  the  dependen-
           cies of shared objects.

           Fake 64-bit executable loaded to check  the  dependen-
           cies of shared objects.


     See attributes(5) for descriptions of the  following  attri-

    |       ATTRIBUTE TYPE        |       ATTRIBUTE VALUE       |
    | Availability                | SUNWtoo                     |


     adb(1), crle(1),  dump(1),  elfdump(1),  ld(1),  ld.so.1(1),
     pvs(1), truss(1),  dlopen(3DL), 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  it cannot be opened for reading, a non-zero
     exit status is returned.


     ldd does not list shared objects explicitly  attached  using

     Using the -d or -r  option  with  shared  objects  can  give
     misleading  results. ldd does a "worst case" analysis of the
     shared objects. However, in practice some or all of the sym-
     bols  reported  as unresolved can be resolved by the execut-
     able file referencing the shared object. The runtime linkers
     preloading mechanism (see LD_PRELOAD) may be employed to add
     dependencies to the object being inspected.

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

Man(1) output converted with man2html