ldd man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]

LDD(1)									LDD(1)

       ldd - list dynamic dependencies of executable files or shared objects

       ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-p] [-s]
	   [-U | -u] [-v] [-w] 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.  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.

       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).

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

	     Check immediate references.

	     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	 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 the Linker and
       Libraries Guide. Object loading can also be affected by relocation pro‐
       cessing. See Lazy Loading under USAGE for more details.

       Some  unresolved	 symbol	 references are not reported by default. These
       unresolved references can be reported with the following options. These
       options	are  only  useful  when	 combined with either the -d or the -r

	     Expose any unresolved symbol errors to explicit parent and exter‐
	     nal references.

	     Expose any unresolved weak symbol references.

       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 exam‐
       ining a dynamic executable, a parent or external reference that can not
       be  resolved is flagged as an error. However by default, when examining
       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 a relocation error.

       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.

       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.

       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.

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

	     This option also displays any unused search paths.

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

       The following additional options are supported:

		   Disables  any  configuration	 file use. Configuration files
		   can be employed to alter default search paths, and  provide
		   alternative object dependencies. See crle(1).

       -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 infor‐
		   mation solely from the object under inspection,  for	 exam‐
		   ple, LD_DEBUG. See ld.so.1(1) and lari(1).

		   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 exe‐
		   cutable is not considered secure if	the  interpreter  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 Secu‐
		   rity under USAGE.

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

		   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 dependencies,  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	 load‐
		   ing as would occur in a running process.

		   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  mes‐

		   Displays  the  search  path	used  to  locate shared object

		   Displays all dependency relationships  incurred  when  pro‐
		   cessing 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).

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

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

       crle(1),	 dump(1),  elfdump(1),	lari(1),  ld(1),  ld.so.1(1),  mdb(1),
       pldd(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.

       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.

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

				  Jun 3, 2008				LDD(1)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net