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 running 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:
Lists the object dependencies if they exist.
Succeeds quietly if dependencies do not exist.
Prints an error message if processing fails.
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.
Check immediate references.
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 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 following 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 dependency that is not bound to by any other object when filename is loaded is an unused object.
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 unreferenced.
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 therefore 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 different objects, or as the other object dependencies evolve.
The following additional options are supported:
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).
Sets the environment variable envar. This option is useful for experimenting with runtime linker environment variables that can adversely affect ldd itself.
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.
Displays the order of execution of initialization sections. The order discovered may be affected by use of the -d or -r options. See Initialization Order under USAGE.
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 since it will occur in a running process.
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.
Displays the search path used to locate shared object dependencies.
Displays all dependency relationships incurred when processing filename. This option also displays any dependency version requirements. See pvs(1).
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 compromise 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 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 (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.
Objects that do not explicitly define their required dependencies 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 initialization 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 -z defs and -z ignore 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.
Fake 32–bit executable loaded to check the dependencies of shared objects.
Fake 64–bit executable loaded to check the dependencies of shared objects.
See attributes(5) for descriptions of the following attributes:
|ATTRIBUTE TYPE||ATTRIBUTE VALUE|
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.
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.