Determine direct shared object dependencies of a Linux binary?

Question

How can I easily find out the direct shared object dependencies of a Linux binary in ELF format?

I'm aware of the ldd tool, but that appears to output all dependencies of a binary, including the dependencies of any shared objects that binary is dependent on.

related http://unix.stackexchange.com/questions/120015/how-to-find-out-the-dynamic-libraries-executables-loads-when-run/220110#220110 — Ciro Santilli OurBigBook.com, May 21 '16 at 20:09

score 299 · Accepted Answer · edited Jun 29 '16 at 20:41

299

You can use readelf to explore the ELF headers. readelf -d will list the direct dependencies as NEEDED sections.

 $ readelf -d elfbin

Dynamic section at offset 0xe30 contains 22 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libssl.so.1.0.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x400520
 0x000000000000000d (FINI)               0x400758
 ...

edited Jun 29 '16 at 20:41

Nathan Kidd

2,919
21
22

answered Jun 05 '11 at 12:06

Mat

202,337
40
393
406

25

This is great. Unlike ldd, readelf can inspect a cross-platform binary (i.e. inspect an ARM executable from x86-64 linux.) – Robert Calhoun Oct 21 '14 at 14:07

score 98 · Answer 2 · edited Aug 23 '16 at 10:55

98

If you want to find dependencies recursively (including dependencies of dependencies, dependencies of dependencies of dependencies and so on)…

You may use ldd command. ldd - print shared library dependencies

edited Aug 23 '16 at 10:55

Sasha

3,599
1
31
52

answered Jul 05 '11 at 23:22

Serge C

2,205
16
23

5

The ldd command works out dependencies of dependencies, which isn't what I want. – Free Wildebeest Jul 06 '11 at 10:05
11

For me this works fine. And it even tells you, which of the libraries could and could not be found. – Philipp F Aug 17 '12 at 07:46
3

ldd would not work with an executable - only for finding out the dependencies of shared libraries it is useful. – Tuxdude Oct 09 '12 at 05:57
2

Tuxdude, why do you think so? What is the reason of ldd's unusability for ELF executables? – Vitaly Isaev Nov 01 '13 at 06:28
1

This is awesome for copiyng required shared libs from development machine to deployment archive. – Tomáš Zato Apr 14 '17 at 09:39
It would be better to put an example of the command in this answer since the linked website may disappear at some point in the future. – jgh Oct 03 '19 at 12:35

score 38 · Answer 3 · edited Feb 08 '19 at 13:59

The objdump tool can tell you this information. If you invoke objdump with the -x option, to get it to output all headers then you'll find the shared object dependencies right at the start in the "Dynamic Section".

For example running objdump -x /usr/lib/libXpm.so.4 on my system gives the following information in the "Dynamic Section":

Dynamic Section:
  NEEDED               libX11.so.6
  NEEDED               libc.so.6
  SONAME               libXpm.so.4
  INIT                 0x0000000000002450
  FINI                 0x000000000000e0e8
  GNU_HASH             0x00000000000001f0
  STRTAB               0x00000000000011a8
  SYMTAB               0x0000000000000470
  STRSZ                0x0000000000000813
  SYMENT               0x0000000000000018
  PLTGOT               0x000000000020ffe8
  PLTRELSZ             0x00000000000005e8
  PLTREL               0x0000000000000007
  JMPREL               0x0000000000001e68
  RELA                 0x0000000000001b38
  RELASZ               0x0000000000000330
  RELAENT              0x0000000000000018
  VERNEED              0x0000000000001ad8
  VERNEEDNUM           0x0000000000000001
  VERSYM               0x00000000000019bc
  RELACOUNT            0x000000000000001b

The direct shared object dependencies are listing as 'NEEDED' values. So in the example above, libXpm.so.4 on my system just needs libX11.so.6 and libc.so.6.

It's important to note that this doesn't mean that all the symbols needed by the binary being passed to objdump will be present in the libraries, but it does at least show what libraries the loader will try to load when loading the binary.

This produces some more output than the other answers, which may or may not be an advantage. — Tomasz Gandor, Apr 01 '21 at 15:32

score 18 · Answer 4 · edited May 23 '17 at 12:34

18

ldd -v prints the dependency tree under "Version information:' section. The first block in that section are the direct dependencies of the binary.

See Hierarchical ldd(1)

edited May 23 '17 at 12:34

Community

1
1

answered Oct 22 '14 at 17:54

Hannes

420
4
8

What is the difference between this and `objdump -x | grep "NEEDED"`? I mean, both are almost exactly the same, I'm just getting one `.so` file more with `ldd` than `objdump`. But the fact the results are not the same makes me wonder which method is more accurate. – m4l490n Jul 13 '20 at 14:34
1

@m4l490n, if your discrepancy name is `linux-vdso.so`, this is a virtual library injected by the kernel into every process. It exists as a file only during kernel build, and then just stored inside the kernel. It is speeding up unprivileged calls as `time()` that do not really require an expensive mode transition. – kkm inactive - support strike Oct 08 '20 at 08:29
2

@m4l490n, using `ldd` on a file is a security risk, as it loads the loader specified in the file itself to load the file and resolve its dependencies. The glaring holes have been patched, but keep in mind that with `ldd` you are one jump away from running the program, it essentially tells the loader to run the program, resolve dependencies and trace them, and stop just at the last moment. Both `objdump` and `readelf` read ELF as data files. `objdump` uses the common bfd library to parse the file, `readelf` is self-contained (read comments at the start of its source for an explanation why). – kkm inactive - support strike Oct 08 '20 at 08:40

Determine direct shared object dependencies of a Linux binary?

4 Answers4

Linked

Related