Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
ldd(1)									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,, 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  ob-
       jects  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 po-
       sition  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  .  Object loading can	also be	affected by relocation
       processing. See Lazy Loading under  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 un-
		referenced 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 in-
       vocation	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  re-
       sult 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  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 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 environ-
		       ment variables  that  are  recognized  by  the  runtime
		       linker  that  can  adversely  affect  ldd, for example,

		       This  option  is	  also	useful	 for   extracting  ad-
		       ditional	   information	  solely   from	  the	object
		       under   inspection,    for    example,  LD_DEBUG.   See and lari(1).

       -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 de-
		       termined. See Security under .

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

       -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 ig-
		       nored. 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 de-
		       pendency	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 ob-

       example%	ldd main =>	/lib/ =>	/lib/ =>	/lib/

       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 =>	  /lib/
       example%	ldd -r main =>	  /lib/ =>	/lib/

       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,,
       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 re-

       example%	ldd -i main =>	./ =>	/lib/ =>	./

	   init	object=./
	   init	object=./
	   init	object=/lib/

       whereas,	when relocations are applied, the initialization section order

       example%	ldd -ir	main

	   init	object=/lib/
	   init	object=./
	   init	object=./

       In   this   case,   makes   reference   to  a  function  in
       /usr/lib/ However, 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  dy-
       namic 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 de-
			       pendencies of shared objects.

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

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

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

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

       ldd prints the record of	shared object path names to  stdout.  The  op-
       tional  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 re-
       sults. 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  ob-

				  23 Feb 2005				ldd(1)


Want to link to this manual page? Use this URL:

home | help