ldd 不同的输出。相同的二进制不同的发行版答案

【问题标题】：ldd different output. Same binary different distrosldd 不同的输出。相同的二进制不同的发行版
【发布时间】：2012-10-03 18:03:11
【问题描述】：

在运行ldd 实用程序以查找httpd 的共享库时，我发现了以下我无法解释的场景：

在我的Ubuntu 盒子上：

leon@lwaldman-linux:~/Uol/Lxc/py_utils/Container_Builder/_builds/usr/sbin$ ldd  httpd 
    linux-gate.so.1 =>  (0xf77b2000)
    libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7712000)
    libpcre.so.0 => not found
    libselinux.so.1 => /lib/i386-linux-gnu/libselinux.so.1 (0xf76f2000)
    libaprutil-1.so.0 => not found
    libcrypt.so.1 => /lib/i386-linux-gnu/libcrypt.so.1 (0xf76c1000)
    libexpat.so.1 => /lib/i386-linux-gnu/libexpat.so.1 (0xf7697000)
    libdb-4.7.so => not found
    libapr-1.so.0 => not found
    libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf767b000)
    libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74d6000)
    /lib/ld-linux.so.2 (0xf77b3000)
    libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf74d1000)

在CentOS 盒子上：

[root@localhost sbin]# ldd httpd 
linux-gate.so.1 =>  (0x008b6000)
libm.so.6 => /lib/libm.so.6 (0x0036f000)
libpcre.so.0 => /lib/libpcre.so.0 (0x00835000)
libselinux.so.1 => /lib/libselinux.so.1 (0x0021f000)
libaprutil-1.so.0 => /usr/lib/libaprutil-1.so.0 (0x00dfa000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x003de000)
libexpat.so.1 => /lib/libexpat.so.1 (0x00695000)
libdb-4.7.so => /lib/libdb-4.7.so (0x0040e000)
libapr-1.so.0 => /usr/lib/libapr-1.so.0 (0x00110000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00257000)
libc.so.6 => /lib/libc.so.6 (0x00e37000)
/lib/ld-linux.so.2 (0x00aae000)
libdl.so.2 => /lib/libdl.so.2 (0x0096d000)
libuuid.so.1 => /lib/libuuid.so.1 (0x007c8000)
libfreebl3.so => /lib/libfreebl3.so (0x00d94000)

为什么 libuuid 和 libfreebl3 列在 CentOS 框中，但未列在 Ubuntu 框中？

我知道httpd ELF 没有将它们列为依赖项：

0x00000001 (NEEDED)                     Shared library: [libm.so.6]
0x00000001 (NEEDED)                     Shared library: [libpcre.so.0]
0x00000001 (NEEDED)                     Shared library: [libselinux.so.1]
0x00000001 (NEEDED)                     Shared library: [libaprutil-1.so.0]
0x00000001 (NEEDED)                     Shared library: [libcrypt.so.1]
0x00000001 (NEEDED)                     Shared library: [libexpat.so.1]
0x00000001 (NEEDED)                     Shared library: [libdb-4.7.so]
0x00000001 (NEEDED)                     Shared library: [libapr-1.so.0]
0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
0x00000001 (NEEDED)                     Shared library: [libc.so.6]

有什么见解吗？

编辑：两个测试中使用的 httpd 二进制文件是同一个（我从 CentOS RPM 解压出来的）。

【问题讨论】：

有些库在 Ubuntu 上找不到，但在 Centos 上可以找到，它们自己可能会拉取其他库。
对于 libuuid 确实如此（libaprutil-1 需要）。但我在 libfreebl3 上找不到任何东西。
你有没有运行'ldd -v'来检查谁调用了libfreebl？
感谢您的提示！ :) ldd -v 表明 libfreebl3 确实是 libcrypt 的依赖项，但仅限于 libcrypt 的 CentOS 版本。在 Ubuntu 版本上未列出）。

标签： ubuntu centos shared-libraries ldd

【解决方案1】：

可能 Apache 是在 Fedora 和 Ubuntu 上使用不同选项构建（编译）的。

也许比较输出

httpd -V

会告诉你更多。

【讨论】：

实际上在这两个测试中我都使用了 CentOS 二进制文件。将编辑问题。
那么“额外”库应该是由 httpd 直接依赖项触发的依赖项，在 Ubuntu 和 Fedora 之间会发生变化，因为这些“直接”依赖项已在两个发行版上使用不同的选项进行编译。编辑：Basile Starynkevitch 的评论似乎同意我的看法。

【解决方案2】：

man ldd(1) 说：

在通常情况下，ldd 调用标准动态链接器（参见 ld.so(8)），并将 LD_TRACE_LOADED_OBJECTS 环境变量设置为 1，这会导致链接器显示库依赖项。但是请注意，在某些情况下，某些版本的 ldd 可以尝试通过直接执行程序来获取依赖信息。因此，您永远不应该在不受信任的情况下使用 ldd 可执行文件，因为这可能导致执行任意代码。处理不受信任的可执行文件时，更安全的选择是：

$ objdump -p /path/to/program | grep NEEDED

根据我的经验，这可以产生比ldd更好的结果。

【讨论】：

【解决方案3】：

libapr-1 在 ubuntu 中称为 libapr-1.0。至少，无论如何它是在 12.04 中。

【讨论】：