1ldd(1)                           User Commands                          ldd(1)
2
3
4

NAME

6       ldd - list dynamic dependencies of executable files or shared objects
7

SYNOPSIS

9       ldd [-d | -r] [-c] [-e envar] [-f] [-i] [-L] [-l] [-p] [-s]
10           [-U | -u] [-v] [-w] filename...
11
12

DESCRIPTION

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

OPTIONS

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

USAGE

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

FILES

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

ATTRIBUTES

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

SEE ALSO

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

DIAGNOSTICS

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

NOTES

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)
Impressum