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

当运行ldd工具找到httpd共享库，我发现以下情形，我只是无法解释：ldd不同的输出。相同的二进制发行版不同

在我Ubuntu箱：

[email protected]:~/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框：

[[email protected] 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解压缩）。

来源

2012-10-03 Leon Waldman

在Ubuntu上找不到一些库，但它们在Centos上找到，他们可能会自己拉库。 –

对于libuuid，确实是这种情况（libaprutil-1需要）。但是我在libfreebl3上找不到任何东西。 –

你运行'ldd -v'来检查谁调用libfreebl？ – mbarthelemy

可以预见的是，Apache在Fedora和Ubuntu上的构建（编译）有不同的选项。

也许比较

httpd -V

输出会告诉你更多关于这一点。

来源

2012-10-03 18:19:01 mbarthelemy

其实在两次测试中，我都使用CentOS Binary。将编辑该问题。 –

然后'额外'库应该是由httpd直接依赖关系触发的依赖关系，它在Ubuntu和Fedora之间有所不同，因为这些'直接'依赖关系已经在两个发行版上用不同的选项编译。编辑：巴西尔Starynkevitch的评论似乎同意我。 – mbarthelemy

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

来源

2012-12-14 13:00:46 Gerry

man ldd(1)说：

在通常情况下，LDD调用标准动态接头（见ld.so（8））与LD_TRACE_LOADED_OBJECTS环境变量设置为1 ，这会导致连接体，以显示该库依赖。但是请注意，在某些情况下，某些版本的ldd 可能会尝试通过直接执行程序来获取依赖关系信息。因此，您不应该在不可信的可执行文件上使用ldd，因为这可能会导致执行任意代码。与不可信可执行文件打交道时，一个更安全的替代方案是：

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

根据我的经验，这可能会产生更好的效果比ldd。

来源

2017-08-04 16:27:19

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

回答

相关问题