问来自linux动态链接器的“无版本信息可用”错误是什么意思？

EN

“无版本信息可用”表示共享对象上的库版本号较低。例如，如果在构建二进制文件的机器上，您的major.minor.patch号是7.15.5，而在安装机器上，major.minor.patch号是7.12.1，那么ld将打印警告。

您可以通过使用与目标操作系统附带的共享对象版本相匹配的库(头文件和共享对象)进行编译来修复此问题。例如，如果你打算安装到Debian3.4.6-9，你就不想在RedHat 4.1.1-21上编译。这是大多数发行版都为特定的linux发行版发行的原因之一。

否则，您可以静态链接。但是，您不希望使用PAM这样的东西来执行此操作，因此您希望实际安装一个与客户机的生产环境相匹配的开发环境(或者至少安装并链接到正确的库版本)。

重命名.so文件(用版本号填充它们)的建议源于共享对象库不使用版本化符号的时代。因此，不要期望使用.so.n.n.n命名方案会有帮助(很多-如果您的系统被破坏了，它可能会有所帮助)。

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

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

来自glibc动态链接器的这条消息实际上意味着所提到的库(在您的例子中是/lib/libpam.so.0)没有VERDEF ELF部分，而二进制文件(在您的例子中是authpam)在VERNEED部分中有这个库(可能是libpam.so.0)的一些版本定义。你可以很容易地在readelf中看到它，只需看看.gnu.version_d和.gnu.version_r部分(或者缺少它们)。

所以这不是符号版本不匹配，因为如果二进制文件想要通过VERNEED获得某个特定的版本，而库没有在其实际的VERDEF中提供它，这将是一个硬链接错误，并且该二进制文件根本不会运行(与this或that相比，就像this )。这是因为二进制文件需要一些版本，但是库没有提供任何关于其版本的信息。

这在实践中意味着什么？通常，与本例中所看到的完全一样--什么都没有，只是忽略了版本控制。东西会坏掉吗？当然，是的，所以其他答案是正确的，因为人们应该在运行时使用与二进制文件在构建时链接到的库相同的库。

更多信息可以在Ulrich Dreppers "ELF Symbol Versioning"中找到。

顺便说一下，当我在一个安装了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等等。