ldd
User Commands ldd(1)NAME
ldd - list dynamic dependencies of executable files or shared objectsSYNOPSIS
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: + 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 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 elf- dump(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 GuideDIAGNOSTICS
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