1ldd(1) User Commands ldd(1)
2
3
4
6 ldd - list dynamic dependencies of executable files or shared objects
7
9 ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-p] [-s]
10 [-U | -u] [-v] [-w] filename...
11
12
14 The ldd utility lists the dynamic dependencies of executable files or
15 shared objects. ldd uses the runtime linker, ld.so.1, to generate the
16 diagnostics. The runtime linker takes the object being inspected and
17 prepares the object as would occur in a running process. By default,
18 ldd triggers the loading of any lazy dependencies.
19
20
21 ldd lists the path names of all shared objects that would be loaded
22 when filename is loaded. ldd expects the shared objects that are being
23 inspected to have execute permission. If a shared object does not have
24 execute permission, ldd issues a warning before attempting to process
25 the file.
26
27
28 ldd processes its input one file at a time. For each file, ldd performs
29 one of the following:
30
31 o Lists the object dependencies if the dependencies exist.
32
33 o Succeeds quietly if dependencies do not exist.
34
35 o Prints an error message if processing fails.
36
37
38 The dynamic objects that are inspected by ldd are not executed. There‐
39 fore, ldd does not list any shared objects explicitly attached using
40 dlopen(3C). To display all the objects in use by a process, or a core
41 file, use pldd(1).
42
44 ldd can also check the compatibility of filename with the shared
45 objects filename uses. With the following options, ldd prints warnings
46 for any unresolved symbol references that would occur when filename is
47 loaded.
48
49 -d Check immediate references.
50
51
52 -r Check both immediate references and lazy references.
53
54
55
56 Only one of the options -d or -r can be specified during any single
57 invocation of ldd.
58
59
60 immediate references are typically to data items used by the executable
61 or shared object code. immediate references are also pointers to func‐
62 tions, and even calls to functions made from a position dependent
63 shared object. lazy references are typically calls to global functions
64 made from a position independent shared object, or calls to external
65 functions made from an executable. For more information on these types
66 of reference, see When Relocations Are Performed in the Linker and
67 Libraries Guide. Object loading can also be affected by relocation pro‐
68 cessing. See Lazy Loading under USAGE for more details.
69
70
71 Some unresolved symbol references are not reported by default. These
72 unresolved references can be reported with the following options. These
73 options are only useful when combined with either the -d or the -r
74 options.
75
76 -p Expose any unresolved symbol errors to explicit parent and exter‐
77 nal references.
78
79
80 -w Expose any unresolved weak symbol references.
81
82
83
84 A shared object can make reference to symbols that should be supplied
85 by the caller of the shared object. These references can be explicitly
86 classified when the shared object is created, as being available from a
87 parent, or simply as being external. See the -M mapfile option of
88 ld(1), and the PARENT and EXTERN symbol definition keywords. When exam‐
89 ining a dynamic executable, a parent or external reference that can not
90 be resolved is flagged as an error. However by default, when examining
91 a shared object, a parent or external reference that can not be
92 resolved is not flagged as an error. The -p option, when used with
93 either the -d or -r options, causes any unresolved parent or external
94 reference to be flagged as a relocation error.
95
96
97 Symbols that are used by relocations may be defined as weak references.
98 By default, if a weak symbol reference can not be resolved, the reloca‐
99 tion is ignored and a zero written to the relocation offset. The -w
100 option, when used with either the -d or the -r options, causes any
101 unresolved relocation against a weak symbol reference to be flagged as
102 a relocation error.
103
104
105 ldd can also check dependency use. With each of the following options,
106 ldd prints warnings for any unreferenced, or unused dependencies that
107 are loaded when filename is loaded. Only when a symbol reference is
108 bound to a dependency, is that dependency deemed used. These options
109 are therefore only useful when symbol references are being checked. If
110 the -r option is not in effect, the -d option is enabled.
111
112
113 A dependency that is defined by an object but is not bound to from that
114 object is an unreferenced dependency. A dependency that is not bound to
115 by any other object when filename is loaded is an unused object.
116
117
118 Dependencies can be located in default system locations, or in loca‐
119 tions that must be specified by search paths. Search paths may be spec‐
120 ified globally, such as the environment variable LD_LIBRARY_PATH.
121 Search paths can also be defined in dynamic objects as runpaths. See
122 the -R option to ld(1). Search paths that are not used to satisfy any
123 dependencies cause unnecessary file system processing.
124
125 -U Displays any unreferenced, or unused dependencies. If an unrefer‐
126 enced dependency is not bound to by other objects loaded with
127 filename, the dependency is also flagged as unused. Cyclic depen‐
128 dencies that are not bound to from objects outside of the cycle
129 are also deemed unreferenced.
130
131 This option also displays any unused search paths.
132
133
134 -u Displays any unused objects.
135
136
137
138 Only one of the options -U or -u can be specified during any single
139 invocation of ldd, although -U is a superset of -u. Objects that are
140 found to be unreferenced, or unused when using the -r option, should be
141 removed as dependencies. These objects provide no references, but
142 result in unnecessary overhead when filename is loaded. When using the
143 -d option, any objects that are found to be unreferenced, or unused are
144 not immediately required when filename is loaded. These objects are
145 candidates for lazy loading. See Lazy Loading under USAGE for more
146 details.
147
148
149 The removal of unused dependencies reduces runtime-linking overhead.
150 The removal of unreferenced dependencies reduces runtime-linking over‐
151 head to a lesser degree. However, the removal of unreferenced dependen‐
152 cies guards against a dependency being unused when combined with dif‐
153 ferent objects, or as the other object dependencies evolve.
154
155
156 The removal of unused search paths can reduce the work required to
157 locate dependencies. This can be significant when accessing files from
158 a file server over a network. Note, a search path can be encoded within
159 an object to satisfy the requirements of dlopen(3C). This search path
160 might not be required to obtain the dependencies of this object, and
161 hence will look unused to ldd.
162
163
164 The following additional options are supported:
165
166 -c Disables any configuration file use. Configuration files
167 can be employed to alter default search paths, and provide
168 alternative object dependencies. See crle(1).
169
170
171 -e envar Sets the environment variable envar.
172
173 This option is useful for experimenting with environment
174 variables that are recognized by the runtime linker that
175 can adversely affect ldd, for example, LD_PRELOAD.
176
177 This option is also useful for extracting additional infor‐
178 mation solely from the object under inspection, for exam‐
179 ple, LD_DEBUG. See ld.so.1(1) and lari(1).
180
181
182 -f Forces ldd to check for an executable file that is not
183 secure. When ldd is invoked by a superuser, by default ldd
184 does not process any executable that is not secure. An exe‐
185 cutable is not considered secure if the interpreter that
186 the executable specifies does not reside under /lib,
187 /usr/lib or /etc/lib. An executable is also not considered
188 secure if the interpreter cannot be determined. See Secu‐
189 rity under USAGE.
190
191
192 -i Displays the order of execution of initialization sections.
193 The order that is discovered can be affected by use of the
194 -d or -r options. See Initialization Order under USAGE.
195
196
197 -L Enables lazy loading. Lazy loading is the default mode of
198 operation when the object under inspection is loaded as
199 part of a process. In this case, any lazy dependencies, or
200 filters, are only loaded into the process when reference is
201 made to a symbol that is defined within the lazy object.
202 The -d or -r options, together with the -L option, can be
203 used to inspect the dependencies, and their order of load‐
204 ing as would occur in a running process.
205
206
207 -l Forces the immediate processing of any filters so that all
208 filtees, and their dependencies, are listed. The immediate
209 processing of filters is now the default mode of operation
210 for ldd. However, under this default any auxiliary filtees
211 that cannot be found are silently ignored. Under the -l
212 option, missing auxiliary filtees generate an error mes‐
213 sage.
214
215
216 -s Displays the search path used to locate shared object
217 dependencies.
218
219
220 -v Displays all dependency relationships incurred when pro‐
221 cessing filename. This option also displays any dependency
222 version requirements. See pvs(1).
223
224
226 Security
227 A superuser should use the -f option only if the executable to be exam‐
228 ined is known to be trustworthy. The use of -f on an untrustworthy exe‐
229 cutable while superuser can compromise system security. If an executa‐
230 bles trustworthyness is unknown, a superuser should temporarily become
231 a regular user. Then invoke ldd as this regular user.
232
233
234 Untrustworthy objects can be safely examined with dump(1) and with
235 mdb(1), as long as the :r subcommand is not used. In addition, a non-
236 superuser can use either the :r subcommand of mdb, or truss(1) to exam‐
237 ine an untrustworthy executable without too much risk of compromise. To
238 minimize risk when using ldd, adb :r, or truss on an untrustworthy exe‐
239 cutable, use the UID "nobody".
240
241 Lazy Loading
242 Lazy loading can be applied directly by specified lazy dependencies.
243 See the -z lazyload option of ld(1). Lazy loading can also be applied
244 indirectly through filters. See the -f option and -F option of ld(1).
245 Objects that employ lazy loading techniques can experience variations
246 in ldd output due to the options used. If an object expresses all its
247 dependencies as lazy, the default operation of ldd lists all dependen‐
248 cies in the order in which the dependencies are recorded in that
249 object:
250
251 example% ldd main
252 libelf.so.1 => /lib/libelf.so.1
253 libnsl.so.1 => /lib/libnsl.so.1
254 libc.so.1 => /lib/libc.so.1
255
256
257
258
259 The lazy loading behavior that occurs when this object is used at run‐
260 time can be enabled using the -L option. In this mode, lazy dependen‐
261 cies are loaded when reference is made to a symbol that is defined
262 within the lazy object. Therefore, combining the -L option with use of
263 the -d and -r options reveals the dependencies that are needed to sat‐
264 isfy the immediate, and lazy references respectively:
265
266 example% ldd -L main
267 example% ldd -d main
268 libc.so.1 => /lib/libc.so.1
269 example% ldd -r main
270 libc.so.1 => /lib/libc.so.1
271 libelf.so.1 => /lib/libelf.so.1
272
273
274
275
276 Notice that in this example, the order of the dependencies that are
277 listed is not the same as displayed from ldd with no options. Even with
278 the -r option, the lazy reference to dependencies might not occur in
279 the same order as would occur in a running program.
280
281
282 Observing lazy loading can also reveal objects that are not required to
283 satisfy any references. These objects, in this example, libnsl.so.1,
284 are candidates for removal from the link-line used to build the object
285 being inspected.
286
287 Initialization Order
288 Objects that do not explicitly define their required dependencies might
289 observe variations in the initialization section order displayed by ldd
290 due to the options used. For example, a simple application might
291 reveal:
292
293 example% ldd -i main
294 libA.so.1 => ./libA.so.1
295 libc.so.1 => /lib/libc.so.1
296 libB.so.1 => ./libB.so.1
297
298 init object=./libB.so.1
299 init object=./libA.so.1
300 init object=/lib/libc.so.1
301
302
303
304
305 whereas, when relocations are applied, the initialization section order
306 is:
307
308 example% ldd -ir main
309 .........
310
311 init object=/lib/libc.so.1
312 init object=./libB.so.1
313 init object=./libA.so.1
314
315
316
317
318 In this case, libB.so.1 makes reference to a function in
319 /usr/lib/libc.so.1. However, libB.so.1 has no explicit dependency on
320 this library. Only after a relocation is discovered is a dependency
321 then established. This implicit dependency affects the initialization
322 section order.
323
324
325 Typically, the initialization section order established when an appli‐
326 cation is executed, is equivalent to ldd with the -d option. The opti‐
327 mum order can be obtained if all objects fully define their dependen‐
328 cies. Use of the ld(1) options -zdefs and -zignore when building
329 dynamic objects is recommended.
330
331
332 Cyclic dependencies can result when one or more dynamic objects refer‐
333 ence each other. Cyclic dependencies should be avoided, as a unique
334 initialization sort order for these dependencies can not be estab‐
335 lished.
336
337
338 Users that prefer a more static analysis of object files can inspect
339 dependencies using tools such as dump(1) and elfdump(1).
340
342 /usr/lib/lddstub Fake 32-bit executable loaded to check the
343 dependencies of shared objects.
344
345
346 /usr/lib/64/lddstub Fake 64-bit executable loaded to check the
347 dependencies of shared objects.
348
349
351 See attributes(5) for descriptions of the following attributes:
352
353
354
355
356 ┌─────────────────────────────┬─────────────────────────────┐
357 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
358 ├─────────────────────────────┼─────────────────────────────┤
359 │Availability │SUNWtoo │
360 └─────────────────────────────┴─────────────────────────────┘
361
363 crle(1), dump(1), elfdump(1), lari(1), ld(1), ld.so.1(1), mdb(1),
364 pldd(1), pvs(1), truss(1), dlopen(3C), attributes(5)
365
366
367 Linker and Libraries Guide
368
370 ldd prints the record of shared object path names to stdout. The
371 optional list of symbol resolution problems is printed to stderr. If
372 filename is not an executable file or a shared object, or if filename
373 cannot be opened for reading, a non-zero exit status is returned.
374
376 Use of the -d or -r option with shared objects can give misleading
377 results. ldd does a worst case analysis of the shared objects. However,
378 in practice, the symbols reported as unresolved might be resolved by
379 the executable file referencing the shared object. The runtime linkers
380 preloading mechanism can be employed to add dependencies to the object
381 being inspected. See LD_PRELOAD.
382
383
384 ldd uses the same algorithm as the runtime linker to locate shared
385 objects.
386
387
388
389SunOS 5.11 3 Jun 2008 ldd(1)