SunOS man pages : ldd (1)
User Commands 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 ] [ -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.
If filename is an executable file, ldd lists the path names
of all shared objects that would be loaded when filename is
loaded.
If filename is a shared object, ldd lists the path names of
all shared objects that would be loaded when filename is
loaded. ldd expects shared objects to have execute permis-
sion. 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 if filename were executed.
- d Checks references to data objects.
-r Checks references to both data objects and functions.
Only one of the above options may be given during any single
invocation of ldd. See Lazy Loading under USAGE.
- 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).
SunOS 5.8 Last change: 5 Jan 2001 1
User Commands ldd(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 super-user, 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 can-
not 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.
-u Displays any unused dependencies. When a symbol refer-
ence is bound to a dependency, that dependency is
deemed used. This option is therefore only useful when
symbol references are being checked. If the -r option
is not in effect, the -d option is enabled.
Objects that are found to be 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
unused when using the -d option are not immediately
required when filename is loaded, and are therefore
candidates for lazy loading (see Lazy Loading under
SunOS 5.8 Last change: 5 Jan 2001 2
User Commands ldd(1)
USAGE).
-v Displays all dependency relationships incurred when
processing filename. This option also displays any
dependency version requirements. See pvs(1).
USAGE
Security
A super-user 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 super-user may comprom-
ise system security. If it is unknown whether or not the
executable to be examined is trustworthy, a super-user
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-super-user 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 data and
function references respectively:
example% ldd -L main
example% ldd -d main
SunOS 5.8 Last change: 5 Jan 2001 3
User Commands ldd(1)
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
Note 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 function 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
SunOS 5.8 Last change: 5 Jan 2001 4
User Commands ldd(1)
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 elfdump(1)
.
FILES
/usr/lib/lddstub
Fake 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 | 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
SunOS 5.8 Last change: 5 Jan 2001 5
User Commands ldd(1)
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.
SunOS 5.8 Last change: 5 Jan 2001 6
|
 |
|
|
