ldd(1) (man pages section 1: User Commands)

man pages section 1: User Commands

ldd(1)

NAME

ldd- list dynamic dependencies of executable files or shared objects

SYNOPSIS

ldd

-d

-r

-c

-f

-i

-L

-l

-s

-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, as it takes the object being inspected and prepares it as it would in a running 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 permission, and 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:

Lists the object dependencies if they exist
Succeeds quietly if dependencies do not exist
Prints an error message if processing fails

OPTIONS

ldd can also check the compatibility offilename 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.

-c: Disable 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).
-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 cannot be determined.
-i: Displays the order of execution of initialization sections.
-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 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, may be used to inspect the dependencies and their order of loading as 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 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).

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 compromise system security. If it is unknown whether or not the executable to be examined is trustworthy, it is suggested that a super-user 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 subcommand of adb or truss(1) to examine an untrustworthy executable without too much risk of compromise. To minimize risk when using ldd, adb :r, or truss on an untrustworthy executable, use the user id "nobody".

Objects that employ lazy loading techniques, either through directly specified lazy dependencies or through filters, 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 
        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.

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 attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWtoo

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 symbols reported as unresolved can be resolved by the executable 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.

SunOS 5.8 Last Revised 2 Sept 1999