Linux 动态链接器出现的“没有可用的版本信息”错误是什么意思？

问题描述：

在我们的产品中，我们提供了一些动态链接到系统库（如“libpam”）的 Linux 二进制文件。在某些客户系统上，当程序运行时，我们在 stderr 上收到以下错误：

./authpam: /lib/libpam.so.0: no version information available (required by authpam)

应用程序运行良好，并执行动态库中的代码。因此，这不是致命错误，实际上只是一个警告。

我认为这是动态链接器的错误，因为系统安装的库缺少可执行文件所需的某些内容。我不太了解动态链接过程的内部原理……而且谷歌搜索这个主题也没有多大帮助。:(

有人知道是什么原因导致了这个错误吗？...我该如何诊断原因？...以及我们如何更改可执行文件以避免此问题？

更新：客户升级到最新版本的 debian“测试版”，但出现了同样的错误。所以这不是过时的 libpam 库。我想我应该了解链接器在抱怨什么？我该如何调查根本原因，等等？

解决方案 1：

“没有可用的版本信息”意味着共享对象上的库版本号较低。例如，如果您在构建二进制文件的计算机上的 major.minor.patch 编号为 7.15.5，而在安装计算机上的 major.minor.patch 编号为 7.12.1，则 ld 将打印警告。

您可以通过使用与目标操作系统附带的共享对象版本相匹配的库（标头和共享对象）进行编译来解决此问题。例如，如果您要安装到 RedHat 3.4.6-9，则不想在 Debian 4.1.1-21 上进行编译。这是大多数发行版都针对特定 Linux 发行版编号发行的原因之一。

否则，您可以静态链接。但是，您不想使用 PAM 之类的东西来执行此操作，因此您需要实际安装与客户的生产环境相匹配的开发环境（或至少安装并链接到正确的库版本）。

建议你重命名 .so 文件（用版本号填充），这源于共享对象库不使用版本符号的时代。所以不要指望使用 .so.nnn 命名方案会有所帮助（很多 - 如果你的系统已被破坏，它可能会有所帮助。）

最后一个选项是使用自定义链接脚本，使用具有不同次要版本号的库进行编译：
http ://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html

为此，您需要编写自定义脚本，并且需要一个自定义安装程序，该安装程序使用自定义脚本针对客户端的共享对象运行 ld。这要求您的客户端在其生产系统上安装 gcc 或 ld。

解决方案 2：

来自 glibc 动态链接器的这条消息实际上意味着提到的库（/lib/libpam.so.0在您的例子中）没有VERDEFELF 部分，而二进制文件（在您的例子中）在部分中有一些此库的authpam版本定义（大概是）。您可以使用 轻松看到它，只需查看和部分（或缺少部分）。VERNEED`libpam.so.0readelf.gnu.version_d`.gnu.version_r

因此，这不是符号版本不匹配，因为如果二进制文件想要通过获取某个特定版本VERNEED，而库在其实际中未提供该版本VERDEF，则会出现硬链接器错误，二进制文件根本无法运行（例如，与此或那个相比）。二进制文件需要某些版本，但库未提供有关其版本的任何信息。

这在实践中意味着什么？通常，正如本例所示 — 没有问题，忽略版本控制，一切照常运行。会出问题吗？当然会，所以其他答案是正确的，因为在运行时应该使用与二进制文件在构建时链接的库相同的库。

更多信息可以在 Ulrich Dreppers 的“ELF 符号版本控制”中找到。

解决方案 3：

顺便说一句，我在安装了 zenoss 监控系统的系统上运行 check_nrpe 时遇到了这个问题。更令人困惑的是，它以 root 用户身份运行良好，但以 zenoss 用户身份运行却不行。

我发现 zenoss 用户有一个 LD_LIBRARY_PATH，这导致它使用 zenoss 库，从而发出这些警告。例如：

root@monitoring:$ echo $LD_LIBRARY_PATH

su - zenoss
zenoss@monitoring:/root$ echo $LD_LIBRARY_PATH
/usr/local/zenoss/python/lib:/usr/local/zenoss/mysql/lib:/usr/local/zenoss/zenoss/lib:/usr/local/zenoss/common/lib::
zenoss@monitoring:/root$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
/usr/lib/nagios/plugins/check_nrpe: /usr/local/zenoss/common/lib/libcrypto.so.0.9.8: no version information available (required by /usr/lib/libssl.so.0.9.8)
(...)
zenoss@monitoring:/root$ LD_LIBRARY_PATH= /usr/lib/nagios/plugins/check_nrpe -H 192.168.61.61 -p 6969 -c check_mq
(...)

所以无论如何，我想说的是：检查你的变量，如LD_LIBRARY_PATH，LD_PRELOAD等。

解决方案 4：

你是如何编译你的应用的？编译器标志是什么？

根据我的经验，当针对广泛的 Linux 系统领域时，请在您愿意支持的最旧版本上构建您的软件包，并且由于更多系统倾向于向后兼容，您的应用程序将继续工作。实际上，这就是库版本控制的全部原因 - 确保向后兼容性。

解决方案 5：

您已经看到过这种情况吗？原因似乎是其中一侧的 libpam 太旧了，可能是那个客户的问题。

或者该版本的链接可能缺失：http ://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html