| |
| | 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 ... |
| |
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.
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. 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 if filename were executed.
- -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 typically calls to global functions made from a position independent shared object,
or calls to external functions made from the 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.
- -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 environment 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 cannot be determined. See Security
under USAGE.
- -i
- 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.
- -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
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 auxiliary filtees generate an error message.
- -s
- Displays the search path used to locate shared object dependencies.
- -u
- Displays any unused dependencies. When a symbol reference 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 USAGE).
- -v
- Displays all dependency relationships incurred when processing filename. This option also displays any dependency version requirements. See pvs(1).
|
| |
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 compromise 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 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".
|
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 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 -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).
|
|
| |
-
/usr/lib/lddstub
- Fake executable loaded to check the dependencies of shared objects.
|
| |
See attributes(5) for descriptions of the following attributes:
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
| Availability | SUNWtoo |
|
| |
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.
|
| |
