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

Question 1

हमारे उत्पाद में हम कुछ लिनक्स बायनेरिज़ को शिप करते हैं जो गतिशील रूप से सिस्टम लाइब्रेरियों जैसे "लिबपैम" से जुड़ते हैं। कुछ ग्राहक प्रणालियों पर, जब प्रोग्राम चलता है, तो हमें stderr पर निम्न त्रुटि मिलती है:

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

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

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

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

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

Question 2

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

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

अन्यथा, आप स्टेटिकली लिंक कर सकते हैं। हालाँकि, आप PAM जैसी किसी चीज़ के साथ ऐसा नहीं करना चाहते हैं, इसलिए आप वास्तव में एक विकास वातावरण स्थापित करना चाहते हैं जो आपके ग्राहक के उत्पादन परिवेश से मेल खाता हो (या सही लाइब्रेरी संस्करणों के विरुद्ध कम से कम स्थापित और लिंक हो।)

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

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

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

Question 3

Glibc डायनामिक लिंकर से इस संदेश का वास्तव में मतलब यह है कि उल्लिखित पुस्तकालय ( /lib/libpam.so.0आपके मामले में) में VERDEFELF खंड नहीं है जबकि बाइनरी ( authpamआपके मामले में) VERNEEDइस पुस्तकालय के लिए खंड में कुछ संस्करण परिभाषाएं हैं (संभवतः, libpam.so.0)। आप इसे आसानी से देख सकते हैं readelf, बस .gnu.version_dऔर .gnu.version_rवर्गों (या इसके अभाव) को देख सकते हैं।

तो यह एक प्रतीक संस्करण बेमेल नहीं है, अगर द्विआधारी के माध्यम से कुछ विशेष संस्करण प्राप्त करना चाहता था क्योंकि VERNEEDऔर पुस्तकालय अपने वास्तविक में यह नहीं प्रदान की थी VERDEF(है कि एक कठिन लिंकर त्रुटि हो जाएगा और बाइनरी सब पर चलाने नहीं होगा की तरह इस इस या उस की तुलना में )। यह है कि द्विआधारी कुछ संस्करणों को चाहता है, लेकिन पुस्तकालय अपने संस्करणों के बारे में कोई जानकारी प्रदान नहीं करता है।

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

अधिक जानकारी उलरिच ड्रेपर में पाई जा सकती है "ELF Symbol Versioning" ।

Question 4

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

मुझे पता चला कि जेनोस उपयोगकर्ता के पास एक 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 आदि की जाँच करें।

Question 5

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

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

Question 6

क्या आपने यह देखा है पहले से ही ? इसका कारण यह है कि शायद उस ग्राहक पर एक बहुत पुराना दायित्व है।

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