ldd(1)
NAME
ldd - list dynamic dependencies of executable files or
shared objects
SYNOPSIS
ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-s] [-U
| -u] [-v] 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, 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.
OPTIONS
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-
enced.
-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
USAGE.
-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
dependencies.
-v Displays all dependency relationships incurred when
processing filename. This option also displays any
dependency version requirements. See pvs(1).
USAGE
Security
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
recommended.
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-
dump(1).
FILES
/usr/lib/lddstub
Fake 32-bit executable loaded to check the dependen-
cies of shared objects.
/usr/lib/64/lddstub
Fake 64-bit executable loaded to check the dependen-
cies of shared objects.
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | SUNWtoo |
|_____________________________|_____________________________|
SEE ALSO
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
DIAGNOSTICS
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.
NOTES
ldd does not list shared objects explicitly attached using
dlopen(3DL).
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