☰

为什么在发行版 X 上完全相同的二进制库链接到的库比在发行版 Y 上要少呢？

tag-icon • tag-icon linux library
为什么在发行版 X 上完全相同的二进制库链接到的库比在发行版 Y 上要少呢？

我有一个第三方二进制库，用于通过 SSL 连接服务器，该库在Cent OS 4 32 位，但在Debian Lenny 32 位当我尝试处理交易时，出现 SSL 初始化错误。

当我在 Debian 上执行ldd该库时，缺少 5 个链接，而ldd在 Cent OS 上有：

libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2
libkrb5.so.3 => /usr/lib/libkrb5.so.3
libcom_err.so.2 => /lib/libcom_err.so.2
libk5crypto.so.3 => /usr/lib/libk5crypto.so.3
libresolv.so.2 => /lib/libresolv.so.2

我怀疑我的问题就在这里。所有这些库都安装在 Debian 系统上，所以我很困惑为什么第三方二进制文件看不到它们。

我已经对每个系统上的第三方二进制文件进行了 md5sum，它们完全相同。

ldd以下是Cent OS 的完整列表：

[root@localhost ~]# ldd /usr/lib/libwebpayclient.so
        libssl.so.4 => /lib/libssl.so.4 (0x0026a000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0x00c41000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00544000)
        libm.so.6 => /lib/tls/libm.so.6 (0x0093e000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00da4000)
        libc.so.6 => /lib/tls/libc.so.6 (0x0066e000)
        libgssapi_krb5.so.2 => /usr/lib/libgssapi_krb5.so.2 (0x008dd000)
        libkrb5.so.3 => /usr/lib/libkrb5.so.3 (0x00394000)
        libcom_err.so.2 => /lib/libcom_err.so.2 (0x00111000)
        libk5crypto.so.3 => /usr/lib/libk5crypto.so.3 (0x00114000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x007da000)
        libdl.so.2 => /lib/libdl.so.2 (0x00135000)
        libz.so.1 => /usr/lib/libz.so.1 (0x004d1000)
        /lib/ld-linux.so.2 (0x008b5000)

请注意，我必须安装包 compat-libstdc++-33.i386 才能解析 libstdc++.so.5

以下是lddDebian 的完整列表：

localhost:~# ldd /usr/lib/libwebpayclient.so
    linux-gate.so.1 =>  (0xb7fcb000)
    libssl.so.4 => not found
    libcrypto.so.4 => not found
    libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7ee5000)
    libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ebf000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7eb2000)
    libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d57000)
    /lib/ld-linux.so.2 (0xb7fcc000)

请注意，我必须安装包 libstdc++5 才能解析 libstdc++.so.5。

用来ln -s修复我得到的2个“未找到”链接：

localhost:~# ldd /usr/lib/libwebpayclient.so
        linux-gate.so.1 =>  (0xb7eff000)
        libssl.so.4 => /usr/lib/libssl.so.4 (0xb7e8e000)
        libcrypto.so.4 => /usr/lib/libcrypto.so.4 (0xb7d31000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7c76000)
        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7c50000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7c43000)
        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7ae8000)
        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7ae4000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7acf000)
        /lib/ld-linux.so.2 (0xb7f00000)

有趣的是，出现了 libz.so.1。所以这就是线索。

Cent OS 上的 SSL 版本是 0.9.7a，而 Debian 上的 SSL 版本是 0.9.8。我敢打赌它链接到的库较少...

答案1

这些 ldd 是否从相同库的相同（md5sums 相同）副本运行？如果某个系统缺少库，ldd 应该报告“未找到”，而不应该只是无法显示任何内容。

共享对象（无论是库还是二进制）所需的库的初始列表是硬编码的，除非重新编译或修改，否则该列表永远不会改变。有一件事可能会打乱苹果的计划，那就是ldd遍历库依赖项列表并显示有关那些库也是如此，因此您可以在不同的系统上合法地拥有不同的库列表，因为指向的库具有不同的包含库集。困惑了吗？

但是，考虑到这两个列表之间的巨大差异，以及其中有一些我从未见过的库（我的 CentOS 系统上似乎没有 libssl.so.4），我将坚持认为“未公开的信息”是导致您问题的根源——就像在某处安装了一堆带有疯狂链接信息的额外库一样。

另外，你的问题不清楚第一次粘贴的 ldd 输出是完整的还是“diff”。请包括满的两个系统的 ldd 输出，删除了所有手动创建的符号链接（还包括您必须创建的符号链接列表，以及它们的源位置和目标位置）。

答案2

问题是 Debian 上的 SSL 版本 (libssl.so.0.9.8) 不再链接到 Cent OS 上的 libssl.so.0.9.7a 所链接的文件。通过将 CentOS 版本复制到 Debian 框并修复 /usr/lib/libssl.so.4 链接，问题就解决了。这对于安全目的来说并不理想，因为如果 Cent OS 更新该文件，我必须记得将其复制过去。为此，我订阅了 Cent OS 4 安全公告。希望第三方能尽快发布更新的库。

相关内容