'\" te .\" Copyright 1989 AT&T All Rights Reserved .\" Copyright (c) 1998, 2015, Oracle and/or its affiliates. All rights reserved. .TH ldd 1 "14 January 2015" "SunOS 5.11" "User Commands" .SH NAME ldd \- list dynamic dependencies of executable files or shared objects .SH SYNOPSIS .LP .nf \fBldd\fR [\fB-d\fR | \fB-r\fR] [\fB-c\fR] [\fB-D\fR] [\fB-e\fR \fIenvar\fR] [\fB-f\fR] [\fB-i\fR] [\fB-L\fR] [\fB-l\fR] [\fB-p\fR] [\fB-s\fR] [\fB-U\fR | \fB-u\fR] [\fB-v\fR] [\fB-w\fR] \fIfilename\fR... .fi .SH DESCRIPTION .sp .LP The \fBldd\fR utility lists the dynamic dependencies of executable files or shared objects. \fBldd\fR uses the runtime linker, \fBld.so.1\fR(1), to generate the diagnostics. The runtime linker takes the file being inspected and prepares the file as would occur in a running process. .sp .LP By default, \fBldd\fR triggers the loading of all shared object dependencies that are associated with the file being inspected. These dependencies include all lazy dependencies, deferred dependencies, and filtees. As such, \fBldd\fR reports the maximum set of possible dependencies. However, during normal process execution, lazy loaded dependencies, deferred dependencies and filtees, are only loaded when a reference to the dependency is made. Many system libraries for example, provide wide ranges of functionality for which they require supporting dependencies. \fBldd\fR reports all such dependencies, but during normal process execution these supporting dependencies may not be required. See \fBLazy Loading\fR under USAGE, and \fILazy Loading of Dynamic Dependencies\fR in \fIOracle Solaris 11.3 Linkers and Libraries Guide\fR. .sp .LP In its simplest form, \fBldd\fR analyzes the dependency requirements of the objects being inspected. \fBldd\fR can also be instructed to analyze the relocation requirements of each object, which result in binding symbol references to symbol definitions. .sp .LP If \fIfilename\fR is a shared object, \fBldd\fR expects the file to have execute permission. If the file does not have execute permission, \fBldd\fR issues a warning before attempting to process the file. .sp .LP The dynamic objects that are inspected by \fBldd\fR are not executed. Therefore, \fBldd\fR does not list any shared objects explicitly attached using \fBdlopen\fR(3C). .sp .LP To display all the objects in use by a process or a core file, use \fBpldd\fR(1). .SH OPTIONS .sp .LP The following options are supported: .sp .ne 2 .mk .na \fB\fB-c\fR\fR .ad .sp .6 .RS 4n Disables any configuration file use. Configuration files can be employed to alter default search paths, and provide alternative object dependencies. See \fBcrle\fR(1). .RE .sp .ne 2 .mk .na \fB\fB-D\fR\fR .ad .sp .6 .RS 4n Skip deferred dependency loading. By default, \fBldd\fR forces the processing of both deferred dependencies and lazy dependencies. See also the \fB-L\fR option. During normal process execution, deferred dependencies are only loaded when the first reference to a deferred dependency is made. When using the \fB-D\fR option, the use of the \fB-d\fR or \fB-r\fR options do not trigger the loading of any deferred dependencies. See the \fB-z\fR \fBdeferred\fR option of \fBld\fR(1). .sp By default, \fBldd\fR does not report deferred filtees. See the \fB-l\fR option. .RE .sp .ne 2 .mk .na \fB\fB-d\fR\fR .ad .sp .6 .RS 4n Check \fBimmediate\fR references. See \fBInterface Verification\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-e\fR \fIenvar\fR\fR .ad .sp .6 .RS 4n Sets the environment variable \fIenvar\fR. .sp This option is useful for experimenting with environment variables that are recognized by the runtime linker that can adversely affect \fBldd\fR, for example, \fBLD_PRELOAD\fR. .sp This option is also useful for extracting additional information solely from the object under inspection, for example, \fBLD_DEBUG\fR. See \fBld.so.1\fR(1). .RE .sp .ne 2 .mk .na \fB\fB-f\fR\fR .ad .sp .6 .RS 4n Forces \fBldd\fR to check for an executable file that is not secure. When \fBldd\fR is invoked by a superuser, by default \fBldd\fR does not process any executable that is not secure. An executable is not considered secure if the interpreter that the executable specifies does not reside under \fB/lib\fR or \fB/usr/lib\fR. An executable is also not considered secure if the interpreter cannot be determined. See \fBSecurity\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-i\fR\fR .ad .sp .6 .RS 4n Displays the order of execution of initialization sections. The order that is discovered can be affected by the use of the \fB-d\fR or \fB-r\fR options. See \fBInitialization Order\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-L\fR\fR .ad .sp .6 .RS 4n Enables lazy loading. By default, \fBldd\fR forces the processing of both lazy dependencies and deferred dependencies. See also the \fB-D\fR option. During normal process execution, lazy loading is the default mode of operation. In this case, any lazy dependencies, or deferred dependencies, are only loaded into the process when reference is made to a symbol that is defined within the lazy object. The \fB-d\fR or \fB-r\fR options, together with the \fB-L\fR option, can be used to inspect the dependencies, and their order of loading as can occur in a running process. See the \fB-z\fR \fBlazyload\fR option of \fBld\fR(1). .RE .sp .ne 2 .mk .na \fB\fB-l\fR\fR .ad .sp .6 .RS 4n Forces the immediate processing of any filters so that all filtees, and their dependencies, are listed. The immediate processing of filters is the default mode of operation for \fBldd\fR. However, under this default any deferred filtees, or auxiliary filtees that cannot be found, are silently ignored. Using the \fB-l\fR option, deferred filtees are listed together with missing auxiliary filtees. .RE .sp .ne 2 .mk .na \fB\fB-p\fR\fR .ad .sp .6 .RS 4n Expose any unresolved symbol errors to explicit \fBparent\fR and \fBexternal\fR references. See \fBExternal Interfaces\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-r\fR\fR .ad .sp .6 .RS 4n Check \fBimmediate\fR and \fBlazy\fR references. See \fBInterface Verification\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-s\fR\fR .ad .sp .6 .RS 4n Displays the search path used to locate shared object dependencies. .RE .sp .ne 2 .mk .na \fB\fB-U\fR\fR .ad .sp .6 .RS 4n Displays any unreferenced, or unused dependencies. If an unreferenced dependency is not bound to by other objects loaded with \fIfilename\fR, the dependency is flagged as unused. Cyclic dependencies that are not bound to from objects outside of the cycle are also deemed unreferenced. This option also displays any unused search paths. See \fBUnused Material\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-u\fR\fR .ad .sp .6 .RS 4n Displays any unused objects. See \fBUnused Material\fR under USAGE. .RE .sp .ne 2 .mk .na \fB\fB-v\fR\fR .ad .sp .6 .RS 4n Displays all dependency relationships incurred when processing \fIfilename\fR. This option also displays any dependency version requirements. See \fBpvs\fR(1). .RE .sp .ne 2 .mk .na \fB\fB-w\fR\fR .ad .sp .6 .RS 4n Expose any unresolved \fBweak\fR symbol references. See \fBWeak References\fR under USAGE. .RE .SH USAGE .SS "External Interfaces" .sp .LP A shared object can make reference to symbols that should be supplied by the caller of the shared object. These references can be explicitly classified when the shared object is created, as being available from a \fBparent\fR, or simply as being \fBexternal\fR. See the \fB-M\fR \fBmapfile\fR option of \fBld\fR(1), and the \fBPARENT\fR and \fBEXTERN\fR symbol definition keywords. .sp .LP When examining a dynamic executable, a dependency reference to a \fBparent\fR or \fBexternal\fR that can not be resolved is flagged as an error. When examining a shared object, a \fBparent\fR or \fBexternal\fR reference that can not be resolved is not flagged as an error. .sp .LP The \fB-p\fR option, when used with either the \fB-d\fR or \fB-r\fR options, causes any unresolved \fBparent\fR or \fBexternal\fR reference to be flagged as an error. .SS "Initialization Order" .sp .LP When a dynamic object is loaded in a process, any initialization code that is provided by the object is executed. The order in which the initialization code from various objects is executed is determined from the dependency relationships of the objects. See \fIInitialization and Termination Routines\fR in \fIOracle Solaris 11.3 Linkers and Libraries Guide\fR. .sp .LP \fBldd\fR can display the order of initialization for the objects it loads. This analysis is primarily useful in discovering cyclic dependencies. The exact order of loading dependencies within a normal process can differ, and hence the actually initialization realized at runtime can also differ from that listed by \fBldd\fR. .sp .LP Objects that do not explicitly define their required dependencies might observe variations in the initialization section order displayed by \fBldd\fR due to the options used. For example, a simple application might reveal: .sp .in +2 .nf example% \fBldd -i main\fR libA.so.1 => ./libA.so.1 libc.so.1 => /lib/libc.so.1 libB.so.1 => ./libB.so.1 init object=./libB.so.1 init object=./libA.so.1 init object=/lib/libc.so.1 .fi .in -2 .sp .sp .LP whereas, when relocations are applied, the initialization section order is: .sp .in +2 .nf example% \fBldd -ir main\fR ......... init object=/lib/libc.so.1 init object=./libB.so.1 init object=./libA.so.1 .fi .in -2 .sp .sp .LP In this case, \fBlibB.so.1\fR makes reference to a function in \fB/lib/libc.so.1\fR. However, \fBlibB.so.1\fR 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. .sp .LP Typically, the initialization section order established when an application is executed, is equivalent to \fBldd\fR with the \fB-d\fR option. The optimum order can be obtained if all objects fully define their dependencies. Use of the \fBld\fR(1) options \fB-z\fR \fBdefs\fR and \fB-z\fR \fBignore\fR when building dynamic objects is recommended. .sp .LP 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. .SS "Interface Verification" .sp .LP \fBldd\fR can check the compatibility of symbol references and symbol definitions for the objects being inspected. With the \fB-d\fR and \fB-r\fR options, \fBldd\fR prints warnings for any unresolved symbol references that can occur when \fIfilename\fR is loaded into a process. .sp .LP Only one of the options \fB-d\fR or \fB-r\fR can be specified during any single invocation of \fBldd\fR. .sp .LP \fBImmediate\fR references are typically to data items used by the executable or shared object code. \fBImmediate\fR references are also pointers to functions, and even calls to functions made from a position \fBdependent\fR shared object. \fBLazy\fR references are typically calls to global functions made from a position \fBindependent\fR shared object, or calls to external functions made from an executable. For more information on these types of reference, see \fIWhen Relocations Are Performed\fR in \fIOracle Solaris 11.3 Linkers and Libraries Guide\fR. .sp .LP Object loading can also be affected by relocation processing. See \fBLazy Loading\fR under USAGE for more details. .SS "Lazy Loading" .sp .LP Lazy loading can be applied directly by establishing lazy dependencies and deferred dependencies. See the \fB-z\fR \fBlazyload\fR option and \fB-z\fR \fBdeferred\fR options of \fBld\fR(1). Lazy loading can also be applied indirectly through filters. See the \fB-f\fR option and \fB-F\fR option of \fBld\fR(1). Objects that employ lazy loading techniques can experience variations in \fBldd\fR output due to the options used. If an object expresses all its dependencies as lazy, the default operation of \fBldd\fR lists all dependencies in the order in which the dependencies are recorded in that object: .sp .in +2 .nf example% \fBldd main\fR libelf.so.1 => /lib/libelf.so.1 libnsl.so.1 => /lib/libnsl.so.1 libc.so.1 => /lib/libc.so.1 .fi .in -2 .sp .sp .LP The lazy loading behavior that occurs when this object is used at runtime can be enabled using the \fB-L\fR option. In this mode, lazy dependencies are loaded when a reference is made to a symbol that is defined within the lazy object. Therefore, combining the \fB-L\fR option with use of the \fB-d\fR and \fB-r\fR options reveals the dependencies that are needed to satisfy the immediate, and lazy references respectively: .sp .in +2 .nf example% \fBldd\fR \fB-L\fR \fBmain\fR example% \fBldd\fR \fB-d\fR \fBmain\fR libc.so.1 => /lib/libc.so.1 example% \fBldd\fR \fB-r\fR \fBmain\fR libc.so.1 => /lib/libc.so.1 libelf.so.1 => /lib/libelf.so.1 .fi .in -2 .sp .sp .LP Notice that in this example, the order of the dependencies that are listed is not the same as displayed from \fBldd\fR with no options. Even with the \fB-r\fR option, the lazy reference to dependencies might not occur in the same order as would occur in a running process. .sp .LP Observing lazy loading can also reveal objects that are not required to satisfy any references. These objects, in this example, \fBlibnsl.so.1\fR, are candidates for removal from the link-line used to build the object being inspected. .SS "Security" .sp .LP A superuser should use the \fB-f\fR option only if the executable to be examined is known to be trustworthy. The use of \fB-f\fR on an untrustworthy executable while superuser can compromise system security. If the trustworthiness of an executable is unknown, a superuser should temporarily become a regular user. Then invoke \fBldd\fR as this regular user. .sp .LP Untrustworthy objects can be safely examined with \fBdump\fR(1), \fBelfdump\fR(1), \fBelfedit\fR(1), and with \fBmdb\fR(1), as long as the \fB:r\fR subcommand is not used. In addition, a non-superuser can use either the \fB:r\fR subcommand of \fBmdb\fR, or \fBtruss\fR(1) to examine an untrustworthy executable without too much risk of compromise. To minimize risk when using \fBldd\fR, \fBmdb :r\fR, or \fBtruss\fR on an untrustworthy executable, use the \fBUID\fR \fB"nobody"\fR. .SS "Unused Material" .sp .LP \fBldd\fR can validate dependency use. Only when a symbol reference is bound to a dependency, is that dependency deemed used. With the \fB-U\fR option and the \fB-U\fR option, \fBldd\fR prints warnings for any unreferenced, or unused dependencies that are loaded when \fIfilename\fR is loaded. These options are useful when symbol references are being checked. If the \fB-r\fR option is not in effect, the \fB-d\fR option is automatically enabled. .sp .LP 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 \fIfilename\fR is loaded is an unused object. .sp .LP Dependencies can be located in default system locations, or in locations that must be specified by search paths. Search paths may be specified globally, such as the environment variable \fBLD_LIBRARY_PATH\fR. Search paths can also be defined in dynamic objects as runpaths. See the \fB-R\fR option to \fBld\fR(1). Search paths that are not used to satisfy any dependencies cause unnecessary file system processing. .sp .LP Only one of the options \fB-U\fR or \fB-u\fR can be specified during any single invocation of \fBldd\fR, although \fB-U\fR is a superset of \fB-u\fR. Objects that are found to be unreferenced, or unused when using the \fB-r\fR option, should be removed as dependencies. These objects provide no references, but result in unnecessary overhead when \fIfilename\fR is loaded. When using the \fB-d\fR option, any objects that are found to be unreferenced, or unused are not immediately required when \fIfilename\fR is loaded. These objects are candidates for lazy loading. See \fBLazy Loading\fR under USAGE for more details. .sp .LP The removal of unused dependencies reduces runtime-linking overhead. The removal of unreferenced dependencies reduces runtime-linking overhead to a lesser degree. However, the removal of unreferenced dependencies guards against a dependency being unused when combined with different objects, or as the other object dependencies evolve. .sp .LP The removal of unused search paths can reduce the work required to locate dependencies. This can be significant when accessing files from a file server over a network. Note, a search path can be encoded within an object to satisfy the requirements of \fBdlopen\fR(3C). This search path might not be required to obtain the dependencies of this object, and hence will look unused to \fBldd\fR. .SS "Weak References" .sp .LP Symbols that are used by relocations may be defined as \fBweak\fR references. By default, if a weak symbol reference can not be resolved, the relocation is ignored and a zero written to the relocation offset. The \fB-w\fR option, when used with either the \fB-d\fR or the \fB-r\fR options, causes any unresolved relocation against a weak symbol reference to be flagged as a relocation error. .SH ATTRIBUTES .sp .LP See \fBattributes\fR(5) for descriptions of the following attributes: .sp .sp .TS tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) . ATTRIBUTE TYPEATTRIBUTE VALUE _ Availabilitysystem/linker .TE .SH SEE ALSO .sp .LP \fBcrle\fR(1), \fBdump\fR(1), \fBelfdump\fR(1), \fBelfedit\fR(1), \fBld\fR(1), \fBld.so.1\fR(1), \fBmdb\fR(1), \fBpldd\fR(1), \fBpvs\fR(1), \fBtruss\fR(1), \fBdlopen\fR(3C), \fBattributes\fR(5) .sp .LP \fIOracle Solaris 11.3 Linkers and Libraries Guide\fR .SH DIAGNOSTICS .sp .LP \fBldd\fR prints the record of shared object path names to \fBstdout\fR. The optional list of symbol resolution problems is printed to \fBstderr\fR. If \fIfilename\fR is not an executable file or a shared object, or if \fIfilename\fR cannot be opened for reading, a non-zero exit status is returned. .SH NOTES .sp .LP Use of the \fB-d\fR or \fB-r\fR option with shared objects can give misleading results. \fBldd\fR 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 preloading mechanism can be employed to add dependencies to the object being inspected. See \fBLD_PRELOAD\fR.