लिनक्स गतिशील लिंकर से "कोई संस्करण जानकारी उपलब्ध नहीं है" त्रुटि का क्या अर्थ है?

Question

हमारे उत्पाद में हम कुछ लिनक्स बाइनरी भेजते हैं जो "libpam" जैसे सिस्टम लाइब्रेरी से गतिशील रूप से लिंक करते हैं।

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

आवेदन ठीक चलाता है और गतिशील पुस्तकालय से कोड निष्पादित करता है: कुछ ग्राहक सिस्टम पर हम जब कार्यक्रम चलाता है stderr पर निम्न त्रुटि मिलता है। तो यह एक घातक त्रुटि नहीं है, यह वास्तव में सिर्फ एक चेतावनी है।

मुझे लगता है कि यह त्रुटि गतिशील लिंकर से आती है जब सिस्टम स्थापित लाइब्रेरी में हमारी निष्पादन योग्य अपेक्षाएं गायब होती हैं। मैं गतिशील लिंकिंग प्रक्रिया के आंतरिक के बारे में ज्यादा नहीं जानता ... और विषय को गुगल करने से ज्यादा मदद नहीं मिलती है। :(

किसी को भी पता है कि इस त्रुटि का कारण बनता है ... कैसे मैं कारण का पता लगाने कर सकते हैं ... और हम कैसे इस समस्या से बचने के लिए हमारी निष्पादनयोग्य को बदल सकता है

अद्यतन?? ग्राहक नवीनतम करने के लिए उन्नत डेबियन "परीक्षण" का संस्करण और एक ही त्रुटि आई। इसलिए यह पुरानी libpam लाइब्रेरी नहीं है। मुझे लगता है कि मैं समझना चाहता हूं कि लिंकर किस बारे में शिकायत कर रहा है? मैं अंतर्निहित कारण, आदि की जांच कैसे कर सकता हूं?

Answer 1

क्या आपने पहले से ही this देखा है? शायद उस ग्राहक पर, पक्ष में से किसी एक पर बहुत पुराना libpam प्रतीत होता है।

या संस्करण के लिए लिंक गायब हो सकते हैं: http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html

Answer 2

"कोई संस्करण जानकारी उपलब्ध नहीं है" का अर्थ है कि साझा ऑब्जेक्ट पर लाइब्रेरी संस्करण संख्या कम है। उदाहरण के लिए, यदि मशीन पर आपका major.minor.patch नंबर 7.15.5 है, जहां आप बाइनरी बनाते हैं, और install.minor.patch संख्या इंस्टॉलेशन मशीन पर 7.12.1 है, तो एलडी चेतावनी प्रिंट करेगा।

आप इसे लाइब्रेरी (हेडर और साझा ऑब्जेक्ट्स) के साथ संकलित करके ठीक कर सकते हैं जो आपके लक्षित ओएस के साथ भेजे गए साझा ऑब्जेक्ट संस्करण से मेल खाता है। उदाहरण के लिए, यदि आप RedHat 3.4.6-9 पर स्थापित करने जा रहे हैं, तो आप डेबियन 4.1.1-21 पर संकलित नहीं करना चाहते हैं। यह उन कारणों में से एक है जो अधिकांश वितरण विशिष्ट लिनक्स डिस्ट्रो संख्याओं के लिए शिप करते हैं।

अन्यथा, आप स्थिर रूप से लिंक कर सकते हैं। हालांकि, आप इसे पीएएम की तरह कुछ नहीं करना चाहते हैं, इसलिए आप वास्तव में एक विकास वातावरण स्थापित करना चाहते हैं जो आपके क्लाइंट के उत्पादन वातावरण से मेल खाता है (या कम से कम सही लाइब्रेरी संस्करणों के खिलाफ स्थापित और लिंक करें।)

आपको सलाह .so फ़ाइलों का नाम बदलने के लिए (संस्करण संख्याओं के साथ उन्हें पैडिंग), उस समय से उत्पन्न होता है जब साझा ऑब्जेक्ट लाइब्रेरी संस्करण संस्करणों का उपयोग नहीं करते थे। तो उम्मीद नहीं है कि .so.nnn नामकरण योजना के साथ खेलना मदद करने जा रहा है (बहुत - यदि सिस्टम को ट्रैश किया गया है तो यह मदद कर सकता है।)

आप अंतिम विकल्प एक पुस्तकालय के साथ एक अलग नाबालिग के साथ संकलित करेंगे संस्करण संख्या, एक कस्टम जोड़ने स्क्रिप्ट का उपयोग: http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/gnu-linker/scripts.html

ऐसा करने के लिए, आप एक कस्टम स्क्रिप्ट लिखने के लिए की आवश्यकता होगी, और आप उस अपने ग्राहक की साझा वस्तुओं के खिलाफ ld चलाता है एक कस्टम संस्थापक की आवश्यकता होगी, कस्टम स्क्रिप्ट का उपयोग । इसकी आवश्यकता है कि आपके ग्राहक के पास उनके उत्पादन प्रणाली पर जीसीसी या एलडी है।

Answer 3

आप अपने ऐप को कैसे संकलित कर रहे हैं? क्या कंपाइलर झंडे?

मेरे अनुभव में, लिनक्स सिस्टम के विशाल क्षेत्र को लक्षित करते समय, अपने पैकेज को पुराने संस्करण पर बनाएं, जिसे आप समर्थन देना चाहते हैं, और क्योंकि अधिक सिस्टम पीछे संगत होते हैं, आपका ऐप काम करना जारी रखेगा। वास्तव में लाइब्रेरी संस्करण के लिए यह संपूर्ण कारण है - पिछड़ा संगतता सुनिश्चित करना।

Answer 4

Fwiw, मुझे यह समस्या थी जब zenoss निगरानी प्रणाली स्थापित सिस्टम पर check_nrpe चला रहा था। भ्रम में जोड़ने के लिए, यह रूट उपयोगकर्ता के रूप में ठीक काम करता था लेकिन ज़ेनॉस उपयोगकर्ता के रूप में नहीं।

मुझे पता चला कि ज़ेनॉस उपयोगकर्ता के पास LD_LIBRARY_PATH था जिसके कारण यह ज़ेनॉस लाइब्रेरीज़ का उपयोग करता था, जो इन चेतावनियों को जारी करता है। अर्थात्:

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 5

क्या 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" में मिल सकती है।