是否可以知道哪个库使用ldd引入了另一个库？

Question

将应用程序与所需的动态库链接后，是否有可能找出哪个确切的库引入了我在列表中看到的另一个库？

例如，今天我遇到了这样一种情况： ldd输出中存在一个本来不应该存在的库，这使应用程序崩溃了。 通过逻辑推论，我可以找出来并隔离问题，然后重建相应的项目以不再包含有问题的库。 但是，是否有可能使用ldd的外部工具在没有任何有关应用程序和它依赖的库的附加知识的情况下进行相同的操作？ （问题是所讨论的库不是由应用程序直接使用，而是由应用程序直接链接到的另一个库使用。）

从本质上讲，看起来好像我在寻找一种将应用程序链接在一起后恢复链接依赖关系图的方法。

Answer 1

ldd最终是一个包装脚本，用于执行LD_TRACE_LOADED_OBJECTS设置了变量LD_TRACE_LOADED_OBJECTS的动态链接程序/加载程序。 例如，以下命令在我的系统中输出与ldd /bin/ls相同的命令：

user@localhost ~ $ LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.* /bin/ls
    linux-gate.so.1 (0xb77bd000)
    libacl.so.1 => /lib/libacl.so.1 (0xb7798000)
    libc.so.6 => /lib/libc.so.6 (0xb75ef000)
    libattr.so.1 => /lib/libattr.so.1 (0xb75e9000)
    /lib/ld-linux.so.2 (0x80065000)

ld.so(8)联机帮助页中记录了许多其他环境变量，用于调整动态链接器。 LD_DEBUG=files是发现特定库被拉出原因的一项特别有趣的工作，它可以跟踪链接器在可执行文件处理过程中要查找的文件：

user@localhost ~ $ LD_TRACE_LOADED_OBJECTS=1 LD_DEBUG=files /lib/ld-linux.so.* /bin/ls
     27831: file=/bin/ls [0];  generating link map
     27831:   dynamic: 0x08064f0c  base: 0x00000000   size: 0x0001e034
     27831:     entry: 0x0804bffc  phdr: 0x08048034  phnum:         10
     27831: 
     27831: 
     27831: file=libacl.so.1 [0];  needed by /bin/ls [0]
     27831: file=libacl.so.1 [0];  generating link map
     27831:   dynamic: 0xb772ced8  base: 0xb7724000   size: 0x0000917c
     27831:     entry: 0xb77257f0  phdr: 0xb7724034  phnum:          7
     27831: 
     27831: 
     27831: file=libc.so.6 [0];  needed by /bin/ls [0]
     27831: file=libc.so.6 [0];  generating link map
     27831:   dynamic: 0xb771fda4  base: 0xb757b000   size: 0x001a8eac
     27831:     entry: 0xb75937b0  phdr: 0xb757b034  phnum:         11
     27831: 
     27831: 
     27831: file=libattr.so.1 [0];  needed by /lib/libacl.so.1 [0]
     27831: file=libattr.so.1 [0];  generating link map
     27831:   dynamic: 0xb7579ef0  base: 0xb7575000   size: 0x000050bc
     27831:     entry: 0xb7575ed0  phdr: 0xb7575034  phnum:          7
     27831: 
    linux-gate.so.1 (0xb7749000)
    libacl.so.1 => /lib/libacl.so.1 (0xb7724000)
    libc.so.6 => /lib/libc.so.6 (0xb757b000)
    libattr.so.1 => /lib/libattr.so.1 (0xb7575000)
    /lib/ld-linux.so.2 (0x80094000)

在上面的示例中，我们看到/bin/ls本身需要libacl.so.1和libc.so.6 ，而libattr.so.1被拉为libacl.so.1的要求。

Answer 2

要知道这一点，您将必须递归使用readelf 。 首先在可执行文件上运行它，然后查找需要的库。 这将告诉您可执行文件直接需要什么。 之后，您应该为每个需要的库迭代地重复该过程，一旦到达有问题的库，您将知道包含路径。

Answer 3

在ldd executable报告的每个库上运行ldd。 递归继续，直到找到罪魁祸首。

或者，运行

objdump -p /path/to/program-or-library | grep NEEDED

递归地