svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
ldd(1)
ldd(1) User Commands ldd(1)
NAME
ldd - list dynamic dependencies of executable files or shared objects
SYNOPSIS
ldd [-cDfilLpsvVw] [-d | -r] [-e envar] [-S dir] [-U | -u] file...
DESCRIPTION
The ldd utility lists the dynamic dependencies of executable files or
shared objects. ldd uses the runtime linker, ld.so.1(1), to generate
the diagnostics. The runtime linker takes the file being inspected and
prepares the file as would occur in a running process.
By default, ldd 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, ldd reports the maximum set of possible dependencies. However,
during normal process execution, lazy loaded dependencies, deferred de‐
pendencies and filtees, are only loaded when a reference to the depen‐
dency is made. Many system libraries for example, provide wide ranges
of functionality for which they require supporting dependencies. ldd
reports all such dependencies, but during normal process execution
these supporting dependencies may not be required. See Lazy Loading un‐
der USAGE, and Lazy Loading of Dynamic Dependencies in Oracle Solaris
11.4 Linkers and Libraries Guide.
In its simplest form, ldd analyzes the dependency requirements of the
objects being inspected. ldd can also be instructed to analyze the re‐
location requirements of each object, which result in binding symbol
references to symbol definitions.
The dynamic objects that are inspected by ldd are not executed. There‐
fore, ldd does not list any shared objects explicitly attached using
dlopen(3C).
To display all the objects in use by a process or a core file, use
pldd(1).
OPTIONS
The following options are supported:
-c
Disables any configuration file use. Configuration files can be em‐
ployed to alter default search paths, and provide alternative ob‐
ject dependencies. See crle(1).
-D
Skip deferred dependency loading. By default, ldd forces the pro‐
cessing of both deferred dependencies and lazy dependencies. See
also the -L option. During normal process execution, deferred de‐
pendencies are only loaded when the first reference to a deferred
dependency is made. When using the -D option, the use of the -d or
-r options do not trigger the loading of any deferred dependencies.
See the -z deferred option of ld(1).
By default, ldd does not report deferred filtees. See the -l op‐
tion.
-d
Check immediate references. See Interface Verification under USAGE.
-e envar
Sets the environment variable envar.
This option is useful for experimenting with environment variables
that are recognized by the runtime linker that can adversely affect
ldd, for example, LD_PRELOAD. See ld.so.1(1).
The -e option should always be used when using the LD_DEBUG envi‐
ronment variable to extract additional information from the object
under inspection. Failure to do so will produce a confusing mix of
debug output from the ldd command with that from the object being
analyzed.
-f
Forces ldd to check for an executable file that is not secure. When
ldd is invoked by with an effective uid of 0, by default ldd 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 /lib or /usr/lib. An executable is also not
considered secure if the interpreter cannot be determined. See Se‐
curity under USAGE.
-i
Displays the order of execution of initialization sections. The or‐
der that is discovered can be affected by the use of the -d or -r
options. See Initialization Order under USAGE.
-L
Enables lazy loading. By default, ldd forces the processing of both
lazy dependencies and deferred dependencies. See also the -D op‐
tion. 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 -d or
-r options, together with the -L option, can be used to inspect the
dependencies, and their order of loading as can occur in a running
process. See the -z lazyload option of ld(1).
-l
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 ldd. However, under
this default any deferred filtees, or auxiliary filtees that cannot
be found, are silently ignored. Using the -l option, deferred fil‐
tees are listed together with missing auxiliary filtees.
-p
Display any unresolved explicit parent and external references. See
External Interfaces under USAGE.
-r
Check immediate and lazy references. See Interface Verification un‐
der USAGE.
-S dir
Specify the system root to be applied to all objects located by
path searching. By default, path searching is interpreted relative
to the system root directory /.
-s
Displays the search path used to locate shared object dependencies.
-U
Displays any unreferenced, or unused dependencies. If an unrefer‐
enced dependency is not bound to by other objects loaded with file,
the dependency is flagged as unused. Cyclic dependencies that are
not bound to from objects outside of the cycle are also deemed un‐
referenced. This option also displays any unused search paths. See
Unused Material under USAGE.
-u
Displays any unused objects. See Unused Material under USAGE.
-v
Displays all dependency relationships incurred when processing
file. This option also displays any dependency version require‐
ments. See pvs(1).
-V
--version
Print version information and immediately exit.
-w
Display any unresolved weak symbol references. See Weak References
under USAGE.
-?
--help
Print usage message and immediately exit.
USAGE
External Interfaces
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
parent, or simply as being external. See the -M mapfile option of
ld(1), and the PARENT and EXTERN symbol definition keywords.
When examining a dynamic executable, a dependency reference to a parent
or external that can not be resolved is flagged as an error. When exam‐
ining a shared object, a parent or external reference that can not be
resolved is not flagged as an error.
The -p option, when used with either the -d or -r options, causes any
unresolved parent or external reference to be flagged as an error.
Initialization Order
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 ini‐
tialization code from various objects is executed is determined from
the dependency relationships of the objects. See Initialization and
Termination Routines in Oracle Solaris 11.4 Linkers and Libraries
Guide.
ldd 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 ldd.
Objects that do not explicitly define their required dependencies might
observe variations in the initialization section order displayed by ldd
due to the options used. For example, a simple application might re‐
veal:
example% ldd -i main
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
whereas, when relocations are applied, the initialization section order
is:
example% ldd -ir main
.........
init object=/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
/lib/libc.so.1. However, libB.so.1 has no explicit dependency on this
library. Only after a relocation is discovered is a dependency then es‐
tablished. This implicit dependency affects the initialization section
order.
Typically, the initialization section order established when an appli‐
cation is executed, is equivalent to ldd with the -d option. The opti‐
mum order can be obtained if all objects fully define their dependen‐
cies. Use of the ld(1) options -z defs and -z ignore when building
dynamic objects is recommended.
Cyclic dependencies can result when one or more dynamic objects refer‐
ence each other. Cyclic dependencies should be avoided, as a unique
initialization sort order for these dependencies can not be estab‐
lished.
Interface Verification
ldd can check the compatibility of symbol references and symbol defini‐
tions for the objects being inspected. With the -d and -r options, ldd
prints warnings for any unresolved symbol references that can occur
when file is loaded into a process.
Only one of the options -d or -r can be specified during any single in‐
vocation of ldd.
Immediate references are typically to data items used by the executable
or shared object code. Immediate references are also pointers to func‐
tions, 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 Oracle Solaris 11.4
Linkers and Libraries Guide.
Object loading can also be affected by relocation processing. See Lazy
Loading under USAGE for more details.
Lazy Loading
Lazy loading can be applied directly by establishing lazy dependencies
and deferred dependencies. See the -z lazyload option and -z deferred
options of ld(1). Lazy loading can also be applied indirectly through
filters. See the -f option and -F option of ld(1). Objects that employ
lazy loading techniques can experience variations in ldd output due to
the options used. If an object expresses all its dependencies as lazy,
the default operation of ldd lists all dependencies in the order in
which the dependencies are recorded in that object:
example% ldd main
libelf.so.1 => /lib/libelf.so.1
libnsl.so.1 => /lib/libnsl.so.1
libc.so.1 => /lib/libc.so.1
The lazy loading behavior that occurs when this object is used at run‐
time can be enabled using the -L option. In this mode, lazy dependen‐
cies are loaded when a 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 reveals the dependencies that are needed to sat‐
isfy the immediate, and lazy references respectively:
example% ldd -L main
example% ldd -d main
libc.so.1 => /lib/libc.so.1
example% ldd -r main
libc.so.1 => /lib/libc.so.1
libelf.so.1 => /lib/libelf.so.1
Notice that in this example, the order of the dependencies that are
listed is not the same as displayed from ldd with no options. Even with
the -r option, the lazy reference to dependencies might not occur in
the same order as would occur in a running process.
Observing lazy loading can 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.
Security
A privileged user should use the -f option only if the executable to be
examined is known to be trustworthy. The use of -f on an untrustworthy
executable while having access to non-basic privileges or authoriza‐
tions can compromise system security. If the trustworthiness of an exe‐
cutable is unknown, the user should temporarily become a regular user,
then invoke ldd as this regular user.
Untrustworthy objects can be safely examined with dump(1), elfdump(1),
elfedit(1), and with mdb(1), as long as the :r subcommand is not used.
In addition, a non-privileged user can use either the :r subcommand of
mdb, or truss(1) to examine an untrustworthy executable without too
much risk of compromise. To minimize risk when using ldd, mdb :r, or
truss on an untrustworthy executable, use the UID "nobody".
Unused Material
ldd can validate dependency use. Only when a symbol reference is bound
to a dependency, is that dependency deemed used. With the -U option and
the -u option, ldd prints warnings for any unreferenced, or unused de‐
pendencies that are loaded when file is loaded. These options are use‐
ful when symbol references are being checked. If the -r option is not
in effect, the -d option is automatically 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 file is loaded is an unused object.
Dependencies can be located in default system locations, or in loca‐
tions that must be specified by search paths. Search paths may be spec‐
ified globally, such as the environment variable LD_LIBRARY_PATH.
Search paths can also be defined in dynamic objects as runpaths. See
the -R option to ld(1). Search paths that are not used to satisfy any
dependencies cause unnecessary file system processing.
Only one of the options -U or -u can be specified during any single in‐
vocation 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. These objects provide no references, but re‐
sult in unnecessary overhead when file is loaded. When using the -d op‐
tion, any objects that are found to be unreferenced, or unused are not
immediately required when file is loaded. These objects are 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 over‐
head to a lesser degree. However, the removal of unreferenced dependen‐
cies guards against a dependency being unused when combined with dif‐
ferent objects, or as the other object dependencies evolve.
The removal of unused search paths can reduce the work required to lo‐
cate 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 dlopen(3C). This search path
might not be required to obtain the dependencies of this object, and
hence will look unused to ldd.
Weak References
Symbols that are used by relocations may be defined as weak references.
By default, if a weak symbol reference can not be resolved, the reloca‐
tion is ignored and a zero written to the relocation offset. The -w op‐
tion, when used with either the -d or the -r options, causes any unre‐
solved relocation against a weak symbol reference to be flagged as a
relocation error.
ATTRIBUTES
See attributes(7) for descriptions of the following attributes:
tab() box; cw(2.75i) |cw(2.75i) lw(2.75i) |lw(2.75i) ATTRIBUTE TYPEAT‐
TRIBUTE VALUE _ Availabilitysystem/linker
SEE ALSO
crle(1), dump(1), elfdump(1), elfedit(1), kldd(1), ld(1), ld.so.1(1),
mdb(1), pldd(1), pvs(1), truss(1), dlopen(3C), attributes(7)
Oracle Solaris 11.4 Linkers and Libraries Guide
DIAGNOSTICS
ldd prints the record of shared object path names to stdout. The op‐
tional list of symbol resolution problems is printed to stderr. If file
is not an executable file or a shared object, or if file cannot be
opened for reading, a non-zero exit status is returned.
NOTES
Use of the -d or -r option with shared objects can give misleading re‐
sults. ldd 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 LD_PRELOAD.
Oracle Solaris 11.4 8 November 2022 ldd(1)