|
Hopefully, this page is exactly what you are looking for, but if not, you can always find further assistance on Unix/Linux Forum!
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
| -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. 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 exe-
cuted. Therefore, 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).
OPTIONS
ldd can also check the compatibility of filename with the
shared objects 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 refer-
ences.
SunOS 5.10 Last change: 23 Feb 2005 1
User Commands ldd(1)
Only one of the options -d or -r can be specified during
any single invocation of ldd. immediate references are typi-
cally 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 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, 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 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 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 Lazy
Loading under USAGE for more details.
The removal of unused dependencies reduces runtime-linking
overhead. The removal of unreferenced dependencies reduces
SunOS 5.10 Last change: 23 Feb 2005 2
User Commands ldd(1)
runtime-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 following additional options are supported:
-c Disables any configuration file use. Confi-
guration files can be employed to alter
default search paths, and provide alterna-
tive 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 information
solely from the object under inspec-
tion, for example, LD_DEBUG. See
ld.so.1(1) 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 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 con-
sidered secure if the interpreter cannot be
determined. See Security under USAGE.
-i Displays the order of execution of initiali-
zation sections. The order that is
discovered can be affected by use of the -d
or -r options. See Initialization Order
under USAGE.
-L Enables lazy loading. Lazy loading is the
default mode of operation when the object
SunOS 5.10 Last change: 23 Feb 2005 3
User Commands ldd(1)
under inspection is loaded as part of a pro-
cess. 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 a running
process.
-l Forces the immediate processing of any
filters so that all filtees, and their
dependencies, are listed. The immediate pro-
cessing 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 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. 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 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 subcom-
mand of mdb, 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 UID "nobody".
SunOS 5.10 Last change: 23 Feb 2005 4
User Commands ldd(1)
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 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 is
used 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.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 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
SunOS 5.10 Last change: 23 Feb 2005 5
User Commands ldd(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 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 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 can
inspect 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:
SunOS 5.10 Last change: 23 Feb 2005 6
User Commands ldd(1)
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | SUNWtoo |
|_____________________________|_____________________________|
SEE ALSO
crle(1), dump(1), elfdump(1), lari(1), ld(1), ld.so.1(1),
mdb(1), pldd(1), pvs(1), truss(1), dlopen(3C), attri-
butes(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 filename cannot be opened for reading, a non-
zero exit status is returned.
NOTES
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 preload-
ing 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 objects.
SunOS 5.10 Last change: 23 Feb 2005 7
Man(1) output converted with
man2html and wrapped by fishsponge
This page was generated on Wed Sep 12 11:25:01 GMT 2007
|
Your favourite pages:
No pages logged yet.
Trying to save cookie... Top 10 most popular pages:
CPAN man page (4290 hits)
(Suse Linux 10.1)
ssh man page (4160 hits)
(Suse Linux 10.1)
adv_cap_autoneg man page (3470 hits)
(Solaris 10 11_06)
sqlite3 man page (3370 hits)
(openSUSE 10.2)
svn man page (3036 hits)
(FreeBSD 6.2)
startproc man page (1856 hits)
(Suse Linux 10.1)
pprosetup man page (1576 hits)
(Solaris 10 11_06)
signal man page (1541 hits)
(Suse Linux 10.1)
netcat man page (1508 hits)
(Suse Linux 10.1)
ssh-socks5-proxy-connect man page (1450 hits)
(Solaris 10 11_06)
|
Man Pages 
