确定 Linux 二进制文件的直接共享对象依赖关系？

Question

如何轻松查找Linux二进制ELF格式文件的直接共享对象依赖关系？

我知道ldd工具，但它似乎输出了二进制文件所有的依赖项，包括它所依赖的任何共享对象的依赖项。

- Free Wildebeest

---

相关内容：http://unix.stackexchange.com/questions/120015/how-to-find-out-the-dynamic-libraries-executables-loads-when-run/220110#220110 - Ciro Santilli OurBigBook.com

Answer 1

您可以使用readelf来探索ELF头文件。readelf -d将列出直接依赖项作为NEEDED部分。

 $ 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
 ...

- Mat

---

很好。与ldd不同，readelf可以检查跨平台二进制文件（即从x86-64 linux检查ARM可执行文件）。 - Robert Calhoun

Answer 2

如果您想递归地查找依赖项（包括依赖项的依赖项、依赖项的依赖项的依赖项等等）...

您可以使用ldd命令。 ldd - 打印共享库依赖项

- Serge C

---

ldd命令会计算出依赖关系的依赖项，这不是我想要的。 - Free Wildebeest

对我来说，这很好用。它甚至会告诉你哪些库已经找到和未找到。 - Philipp F

ldd 不能用于可执行文件 - 它只能用于查找共享库的依赖关系。 - Tuxdude

Tuxdude，你为什么这样认为？ldd对ELF可执行文件无法使用的原因是什么？ - Vitaly Isaev

这对于从开发机器复制所需的共享库到部署归档非常棒。 - Tomáš Zato

最好在这个答案中放一个命令的例子，因为链接的网站将来可能会消失。 - jgh

Answer 3

objdump工具可以告诉你这些信息。如果你使用-x选项调用objdump，让它输出所有的头文件，那么你就会在“Dynamic Section”中找到共享对象依赖关系，它们位于开头。

例如，在我的系统上运行objdump -x /usr/lib/libXpm.so.4，会在“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

直接共享对象依赖关系列在“NEEDED”值中。因此，在上面的示例中，我的系统上的libXpm.so.4只需要libX11.so.6和libc.so.6。

需要注意的是，这并不意味着传递给objdump的二进制文件所需的所有符号都存在于库中，但至少可以显示加载器在加载二进制文件时将尝试加载哪些库。

- Free Wildebeest

---

这会产生比其他答案更多的输出，这可能是一个优点，也可能不是。 - Tomasz Gandor

Answer 4

ldd -v 会在“版本信息:”部分下打印依赖树。该部分的第一个块是二进制文件的直接依赖项。

请参见 Hierarchical ldd(1)

- Hannes

---

这和 objdump -x <binary> | grep "NEEDED" 有什么区别呢？我的意思是，两者几乎完全相同，只是用 ldd 比 objdump 多获取了一个 .so 文件。但结果不同让我想知道哪种方法更准确。 - m4l490n

@m4l490n，如果您的差异名称是linux-vdso.so，这是由内核注入到每个进程中的虚拟库。它仅在内核构建期间存在为文件，然后只存储在内核中。它加速了不需要昂贵模式转换的非特权调用，例如time（）。 - kkm

@m4l490n，使用ldd命令检查文件存在安全风险，因为它会加载文件中指定的加载器来加载文件并解析其依赖项。这些漏洞已经被修补，但请记住，使用ldd命令只需一步即可运行程序，它实际上告诉加载器运行程序、解决依赖关系并跟踪它们，并在最后一刻停止。objdump和readelf都将ELF文件作为数据文件进行读取。objdump使用常见的bfd库来解析文件，而readelf则是自包含的（请阅读其源代码开头的注释以获取说明）。 - kkm