ldd(1) 맨 페이지 - 윈디하나의 솔라나라

개요

섹션
맨 페이지 이름
검색(S)

ldd(1)

ldd(1)                           User Commands                          ldd(1)



NAME
       ldd - list dynamic dependencies of executable files or shared objects

SYNOPSIS
       ldd [-cDfilLpsvVw] [-d | -r] [-e envar] [-S dir] [-U | -u] file...

DESCRIPTION
       The  ldd  utility lists the dynamic dependencies of executable files or
       shared objects. ldd uses the runtime linker,  ld.so.1(1),  to  generate
       the  diagnostics. The runtime linker takes the file being inspected and
       prepares the file as would occur in a running process.


       By default, ldd triggers the loading of all shared object  dependencies
       that  are  associated with the file being inspected. These dependencies
       include all lazy dependencies, deferred dependencies, and  filtees.  As
       such,  ldd  reports  the maximum set of possible dependencies. However,
       during normal process execution,  lazy  loaded  dependencies,  deferred
       dependencies  and  filtees,  are  only  loaded  when a reference to the
       dependency is made. Many system libraries  for  example,  provide  wide
       ranges of functionality for which they require supporting dependencies.
       ldd reports all such dependencies, but during normal process  execution
       these  supporting  dependencies  may  not be required. See Lazy Loading
       under USAGE, and Lazy Loading of Dynamic Dependencies in Oracle Solaris
       11.4 Linkers and Libraries Guide.


       In  its  simplest form, ldd analyzes the dependency requirements of the
       objects being inspected. ldd can also  be  instructed  to  analyze  the
       relocation  requirements of each object, which result in binding symbol
       references to symbol definitions.


       The dynamic objects that are inspected by ldd are not executed.  There‐
       fore,  ldd  does  not list any shared objects explicitly attached using
       dlopen(3C).


       To display all the objects in use by a process  or  a  core  file,  use
       pldd(1).

OPTIONS
       The following 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 crle(1).


       -D

           Skip  deferred  dependency loading. By default, ldd forces the pro‐
           cessing of both deferred dependencies and  lazy  dependencies.  See
           also  the  -L  option.  During  normal  process execution, deferred
           dependencies are only loaded when the first reference to a deferred
           dependency  is made. When using the -D option, the use of the -d or
           -r options do not trigger the loading of any deferred dependencies.
           See the -z  deferred option of ld(1).

           By  default,  ldd  does  not  report  deferred  filtees. See the -l
           option.


       -d

           Check immediate references. See Interface Verification under USAGE.


       -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, for example, LD_PRELOAD.

           This option is also useful for  extracting  additional  information
           solely from the object under inspection, for example, LD_DEBUG. See
           ld.so.1(1).


       -f

           Forces ldd to check for an executable file that is not secure. When
           ldd  is  invoked by with an effective uid of 0, by default ldd does
           not process any executable that is not secure. An executable is not
           considered  secure if the interpreter that the executable specifies
           does not reside under /lib or /usr/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  sections.  The
           order that is discovered can be affected by the use of the -d or -r
           options. See Initialization Order under USAGE.


       -L

           Enables lazy loading. By default, ldd forces the processing of both
           lazy  dependencies  and  deferred  dependencies.  See  also  the -D
           option. During  normal  process  execution,  lazy  loading  is  the
           default  mode of operation. In this case, any lazy dependencies, or
           deferred dependencies, are only loaded into the process when refer‐
           ence  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 can occur
           in a running process. See the -z  lazyload option of ld(1).


       -l

           Forces the immediate processing of any filters so that all filtees,
           and  their  dependencies,  are  listed. The immediate processing of
           filters is the default mode of operation for  ldd.  However,  under
           this default any deferred filtees, or auxiliary filtees that cannot
           be found, are silently ignored. Using the -l option, deferred  fil‐
           tees are listed together with missing auxiliary filtees.


       -p

           Display any unresolved explicit parent and external references. See
           External Interfaces under USAGE.


       -r

           Check immediate and lazy  references.  See  Interface  Verification
           under USAGE.


       -S dir

           Specify  the  system  root  to be applied to all objects located by
           path searching. By default, path searching is interpreted  relative
           to the system root directory /.


       -s

           Displays the search path used to locate shared object dependencies.


       -U

           Displays  any  unreferenced, or unused dependencies. If an unrefer‐
           enced dependency is not bound to by other objects loaded with file,
           the  dependency  is flagged as unused. Cyclic dependencies that are
           not bound to from objects outside of  the  cycle  are  also  deemed
           unreferenced.  This  option  also displays any unused search paths.
           See Unused Material under USAGE.


       -u

           Displays any unused objects. See Unused Material under USAGE.


       -v

           Displays all  dependency  relationships  incurred  when  processing
           file.  This  option  also  displays any dependency version require‐
           ments. See pvs(1).


       -V
       --version

           Print version information and immediately exit.



       -w

           Display any unresolved weak symbol references. See Weak  References
           under USAGE.


       -?
       --help

           Print usage message and immediately exit.




USAGE
   External Interfaces
       A  shared  object can make reference to symbols that should be supplied
       by the caller of the shared object. These references can be  explicitly
       classified when the shared object is created, as being available from a
       parent, or simply as being external. See  the  -M   mapfile  option  of
       ld(1), and the PARENT and EXTERN symbol definition keywords.


       When examining a dynamic executable, a dependency reference to a parent
       or external that can not be resolved is flagged as an error. When exam‐
       ining  a  shared object, a parent or external reference that can not be
       resolved is not flagged as an error.


       The -p option, when used with either the -d or -r options,  causes  any
       unresolved parent or external reference to be flagged as an error.

   Initialization Order
       When  a  dynamic object is loaded in a process, any initialization code
       that is provided by the object is executed. The order in which the ini‐
       tialization  code  from  various objects is executed is determined from
       the dependency relationships of the  objects.  See  Initialization  and
       Termination  Routines  in  Oracle  Solaris  11.4  Linkers and Libraries
       Guide.


       ldd can display the order of initialization for the objects  it  loads.
       This  analysis  is primarily useful in discovering cyclic dependencies.
       The exact order of loading dependencies within  a  normal  process  can
       differ,  and  hence the actually initialization realized at runtime can
       also differ from that listed by ldd.


       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
       reveal:

         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
       is:

         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
       /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 sec‐
       tion 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 -z  defs and -z  ignore 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‐
       lished.

   Interface Verification
       ldd can check the compatibility of symbol references and symbol defini‐
       tions for the objects being inspected. With the -d and -r options,  ldd
       prints  warnings  for  any  unresolved symbol references that can occur
       when file is loaded into a process.


       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  func‐
       tions,  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 information on these  types
       of reference, see When Relocations Are Performed in Oracle Solaris 11.4
       Linkers and Libraries Guide.


       Object loading can also be affected by relocation processing. See  Lazy
       Loading under USAGE for more details.

   Lazy Loading
       Lazy  loading can be applied directly by establishing lazy dependencies
       and deferred dependencies. See the -z  lazyload option and -z  deferred
       options  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 dependencies in the order in
       which the dependencies are recorded in that object:

         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 a 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 process.


       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.

   Security
       A privileged user should use the -f option only if the executable to be
       examined is known to be trustworthy. The use of -f on an  untrustworthy
       executable  while  having  access to non-basic privileges or authoriza‐
       tions can compromise system security. If the trustworthiness of an exe‐
       cutable  is unknown, the user should temporarily become a regular user,
       then invoke ldd as this regular user.


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

   Unused Material
       ldd  can validate dependency use. Only when a symbol reference is bound
       to a dependency, is that dependency deemed used. With the -U option and
       the  -u  option,  ldd  prints  warnings for any unreferenced, or unused
       dependencies that are loaded when file is  loaded.  These  options  are
       useful  when  symbol  references are being checked. If the -r option is
       not in effect, the -d option is automatically 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 file is loaded is an unused object.


       Dependencies can be located in default system locations,  or  in  loca‐
       tions that must be specified by search paths. Search paths may be spec‐
       ified globally,  such  as  the  environment  variable  LD_LIBRARY_PATH.
       Search  paths  can  also be defined in dynamic objects as runpaths. See
       the -R option to ld(1). Search paths that are not used to  satisfy  any
       dependencies cause unnecessary file system processing.


       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 file is loaded. When using the -d
       option, any objects that are found to be unreferenced,  or  unused  are
       not  immediately required when file is loaded. These objects are candi‐
       dates 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 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 removal of unused search paths can  reduce  the  work  required  to
       locate  dependencies. This can be significant when accessing files from
       a file server over a network. Note, a search path can be encoded within
       an  object  to satisfy the requirements of dlopen(3C). This search path
       might not be required to obtain the dependencies of  this  object,  and
       hence will look unused to ldd.

   Weak References
       Symbols that are used by relocations may be defined as weak references.
       By default, if a weak symbol reference can not be resolved, the reloca‐
       tion  is  ignored  and  a zero written to the relocation offset. The -w
       option, when used with either the -d or  the  -r  options,  causes  any
       unresolved  relocation against a weak symbol reference to be flagged as
       a relocation error.

ATTRIBUTES
       See attributes(7) for descriptions of the following attributes:


       tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE  TYPEAT‐
       TRIBUTE VALUE _ Availabilitysystem/linker


SEE ALSO
       crle(1),  dump(1),  elfdump(1), elfedit(1), kldd(1), ld(1), ld.so.1(1),
       mdb(1), pldd(1), pvs(1), truss(1), dlopen(3C), attributes(7)


       Oracle Solaris 11.4 Linkers and Libraries Guide

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

NOTES
       Use  of  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,  the  symbols reported as unresolved might be resolved by
       the executable file referencing the shared object. The runtime  linkers
       preloading  mechanism can be employed to add dependencies to the object
       being inspected. See LD_PRELOAD.



Oracle Solaris 11.4               3 Nov 2021                            ldd(1)
맨 페이지 내용의 저작권은 맨 페이지 작성자에게 있습니다.
RSS ATOM XHTML 5 CSS3