User Commands ldd(1)
NAME
ldd - list dynamic dependencies of executable files or
shared objectsSYNOPSIS
ldd [-d | -r] [-c] [-D] [-e envar] [-f] [-i] [-L] [-l] [-p]
[-s] [-U | -u] [-v] [-w] filename...
DESCRIPTION
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 aswould occur in a running process. By default, ldd triggers
the loading of any lazy dependencies, and deferred dependen-
cies.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 exe-
cuted. Therefore, ldd does not list any shared objects
explicitly attached using dlopen(3C). To display all theobjects in use by a process, or a core file, use pldd(1).
OPTIONSldd 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 loaded.-d Check immediate references.
SunOS 5.11 Last change: 17 May 2010 1
User Commands ldd(1)
-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 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 underUSAGE 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 whencombined with either the -d or the -r options.
-p Expose any unresolved symbol errors to explicit parent
and external references.-w Expose any unresolved weak symbol references.
A shared object can make reference to symbols that should besupplied by the caller of the shared object. These refer-
ences can be explicitly classified when the shared object is created, as being available from a parent, or simply asbeing external. See the -M mapfile option of ld(1), and the
PARENT and EXTERN symbol definition keywords. When examining a dynamic executable, a parent or external reference that can not be resolved is flagged as an error. However bydefault, when examining a shared object, a parent or exter-
nal reference that can not be resolved is not flagged as anerror. 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 relocation is ignored and a zero written toSunOS 5.11 Last change: 17 May 2010 2
User Commands ldd(1)
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 reloca-
tion error.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 boundto 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. Dependencies can be located in default system locations, or in locations that must be specified by search paths. Search paths may be specified globally, such as the environmentvariable 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.-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. This option also displays any unused search paths.-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 whenusing the -r option, should be removed as dependencies.
These objects provide no references, but result in unneces-
sary 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 LazySunOS 5.11 Last change: 17 May 2010 3
User Commands ldd(1)
Loading under USAGE for more details.
The removal of unused dependencies reduces runtime-linking
overhead. The removal of unreferenced dependencies reducesruntime-linking overhead to a lesser degree. However, the
removal of unreferenced dependencies guards against a depen-
dency being unused when combined with different 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 thisobject, and hence will look unused to ldd.
The following additional options are supported:-c Disables any configuration file use. Configura-
tion 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 processing of both lazy dependen-
cies and deferred dependencies. See also the -L
option. During normal process execution, deferred dependencies are only loaded when the first runtime binding to a deferred reference ismade. 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).-e envar Sets the environment variable envar.
This option is useful for experimenting with environment variables that are recognized by theruntime linker that can adversely affect ldd,
for example, LD_PRELOAD.
This option is also useful for extracting addi-
tional information solely from the object underinspection, for example, LD_DEBUG. See
ld.so.1(1) and lari(1).SunOS 5.11 Last change: 17 May 2010 4
User Commands ldd(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 interpreter that the executable specifies does not reside under /lib, /usr/lib or /etc/lib. An executable is also not considered secure if the interpretercannot be determined. See Security under USAGE.
-i Displays the order of execution of initializa-
tion sections. The order that is discovered canbe affected by 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 anddeferred 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 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 arunning 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 isnow the default mode of operation for ldd. How-
ever, under this default any auxiliary filtees that cannot be found are silently ignored. Underthe -l option, missing auxiliary filtees gen-
erate an error message.-s Displays the search path used to locate shared
object dependencies.-v Displays all dependency relationships incurred
when processing filename. This option also displays any dependency version requirements. See pvs(1).SunOS 5.11 Last change: 17 May 2010 5
User Commands ldd(1)
USAGE
SecurityA superuser 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 superuser can compromise system security. If an executables trustworthyness is unknown, a superuser should temporarily become a regularuser. 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 :rsubcommand is not used. In addition, a non-superuser can use
either the :r subcommand of mdb, or truss(1) to examine anuntrustworthy executable without too much risk of comprom-
ise. To minimize risk when using ldd, mdb :r, or truss on an
untrustworthy executable, use the UID "nobody". Lazy Loading Lazy loading can be applied directly by specified lazydependencies. See the -z lazyload option of ld(1). Lazy
loading can also be applied indirectly through filters. Seethe -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 allits 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 isused at runtime can 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
reveals the dependencies that are needed to satisfy the immediate, and lazy references respectively:example% ldd -L main
example% ldd -d main
libc.so.1 => /lib/libc.so.1example% ldd -r main
libc.so.1 => /lib/libc.so.1 libelf.so.1 => /lib/libelf.so.1SunOS 5.11 Last change: 17 May 2010 6
User Commands ldd(1)
Notice that in this example, the order of the dependenciesthat 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 thelink-line used to build the object being inspected.
Initialization OrderObjects that do not explicitly define their required depen-
dencies might observe variations in the initialization sec-
tion 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 /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 whenan application is executed, is equivalent to ldd with the -d
SunOS 5.11 Last change: 17 May 2010 7
User Commands ldd(1)
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 recom-
mended. Cyclic dependencies can 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 caninspect dependencies using tools such as dump(1) and elf-
dump(1). FILES/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.ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | developer/linker ||_____________________________|_____________________________|
SEE ALSO
crle(1), dump(1), elfdump(1), elfedit(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 DIAGNOSTICSldd 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 sharedSunOS 5.11 Last change: 17 May 2010 8
User Commands ldd(1)
object, or if filename cannot be opened for reading, a non-
zero exit status is returned. NOTESUse 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 filereferencing the shared object. The runtime linkers preload-
ing mechanism can be employed to add dependencies to theobject being inspected. See LD_PRELOAD.
ldd uses the same algorithm as the runtime linker to locate
shared objects.SunOS 5.11 Last change: 17 May 2010 9