linux動態鏈接器的“沒有版本信息可用”錯誤是什么意思？

Question

在我們的產品中，我們發布了一些動態鏈接到“libpam”等系統庫的linux二進制文件。 在某些客戶系統上，當程序運行時，我們在stderr上收到以下錯誤：

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

應用程序運行正常並從動態庫執行代碼。 所以這不是一個致命的錯誤，它只是一個警告。

我認為當系統安裝庫缺少我們的可執行文件期望的東西時，這是來自動態鏈接器的錯誤。 我不太了解動態鏈接過程的內部結構......並且谷歌搜索主題並沒有多大幫助。 :(

任何人都知道導致此錯誤的原因 ......我怎么能診斷原因？ ...以及我們如何更改可執行文件以避免此問題？

更新：客戶升級到最新版本的debian“testing”並發生了同樣的錯誤。 所以它不是一個過時的libpam庫。 我想我想了解鏈接器在抱怨什么？ 我該如何調查根本原因等？

Answer 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。

Answer 2

來自glibc動態鏈接器的這個消息實際意味着所提到的庫（在你的情況下是/lib/libpam.so.0 ）沒有VERDEF ELF部分，而二進制文件（在你的情況下是authpam ）有一些版本定義此庫的VERNEED部分（可能是libpam.so.0 ）。 您可以使用readelf輕松查看它，只需查看.gnu.version_d和.gnu.version_r部分（或缺少部分）。

所以它不是符號版本不匹配，因為如果二進制文件想要通過VERNEED獲得某個特定版本並且庫沒有在其實際的VERDEF提供它，那將是一個硬鏈接器錯誤並且二進制文件根本不會運行（像這樣比起這個或那個 ）。 這是二進制文件需要一些版本，但該庫不提供有關其版本的任何信息。

這在實踐中意味着什么？ 通常，正是在這個例子中看到的 - 沒有什么，只是忽略了版本控制。 事情會破裂嗎？ 當然，是的，所以其他答案是正確的，因為在運行時應該使用與構建時鏈接到的二進制文件庫相同的庫。

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

Answer 3

Fwiw，我在安裝了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等。

Answer 4

你是如何編譯你的應用程序的？ 什么編譯器標志？

根據我的經驗，當針對Linux系統的廣闊領域時，在您願意支持的最舊版本上構建軟件包，並且因為更多系統往往是向后兼容的，所以您的應用程序將繼續工作。 實際上，這是庫版本控制的全部原因 - 確保向后兼容性。

Answer 5

你見過這個嗎？ 原因似乎是其中一方非常老的libpam，可能是該客戶。

或者可能缺少該版本的鏈接： http ： //www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html