c++ - सबस - साझा वस्तुओं(.so), स्थिर पुस्तकालयों(.a), और डीएलएल(.so) के बीच अंतर?




सार्वजनिक पुस्तकालय का पूर्ण व्यय किसके द्वारा किया जाता है (3)

मैं लिनक्स में पुस्तकालयों के संबंध में कुछ बहस में शामिल हूं, और कुछ चीजों की पुष्टि करना चाहता हूं।

यह मेरी समझ के लिए है (अगर मैं गलत हूं तो कृपया मुझे सही करें और मैं बाद में अपनी पोस्ट संपादित करूंगा), कि एप्लिकेशन बनाने के दौरान पुस्तकालयों का उपयोग करने के दो तरीके हैं:

  1. स्टेटिक लाइब्रेरीज़ (एए फाइलें): लिंक समय पर, संपूर्ण लाइब्रेरी की एक प्रति अंतिम एप्लिकेशन में डाल दी जाती है ताकि पुस्तकालय के भीतर कार्य हमेशा कॉलिंग एप्लिकेशन पर उपलब्ध हो
  2. साझा ऑब्जेक्ट्स (.so फ़ाइलें): लिंक समय पर, ऑब्जेक्ट को इसके एपीआई के विरुद्ध संबंधित हेडर (.h) फ़ाइल के माध्यम से सत्यापित किया जाता है। पुस्तकालय वास्तव में रन टाइम तक उपयोग नहीं किया जाता है, जहां इसकी आवश्यकता होती है।

स्थिर पुस्तकालयों का स्पष्ट लाभ यह है कि वे पूरे एप्लिकेशन को आत्मनिर्भर होने की अनुमति देते हैं, जबकि गतिशील पुस्तकालयों का लाभ यह है कि ".so" फ़ाइल को प्रतिस्थापित किया जा सकता है (यानी: अगर किसी सुरक्षा के कारण इसे अपडेट किया जाना चाहिए बग) बेस एप्लिकेशन को पुनः संयोजित करने की आवश्यकता के बिना।

मैंने सुना है कि कुछ लोग साझा वस्तुओं और गतिशील लिंक्ड लाइब्रेरीज़ (डीएलएल) के बीच भेद बनाते हैं, भले ही वे दोनों ".so" फाइलें हों। लिनक्स या किसी अन्य POSIX अनुपालन ओएस (यानी: MINIX, यूनिक्स, क्यूएनएक्स, आदि) पर सी / सी ++ विकास की बात आती है जब साझा वस्तुओं और डीएलएल के बीच कोई अंतर है? मुझे बताया गया है कि एक महत्वपूर्ण अंतर (अब तक) यह है कि साझा वस्तुओं का उपयोग रन टाइम पर किया जाता है, जबकि डीएलएल को एप्लिकेशन के भीतर डलोपेन () कॉल का उपयोग करके पहले खोला जाना चाहिए।

आखिरकार, मैंने कुछ डेवलपर्स को "साझा अभिलेखागार" का भी उल्लेख किया है, जो मेरी समझ के लिए, स्थिर पुस्तकालय भी हैं, लेकिन इन्हें सीधे किसी एप्लिकेशन द्वारा उपयोग नहीं किया जाता है। इसके बजाए, अन्य स्थैतिक पुस्तकालय साझा संग्रह से कुछ (लेकिन सभी नहीं) कार्यों / संसाधनों को खींचने के लिए "साझा अभिलेखागार" के खिलाफ लिंक करेंगे जो स्थिर पुस्तकालय में बनाए जा रहे हैं।

आपकी सहायता के लिए अग्रिम धन्यवाद।

अद्यतन करें

जिस संदर्भ में इन शर्तों को मुझे प्रदान किया गया था, मुझे इन शर्तों में थोड़ा अंतर मिला है, जो कि मेरे उद्योग में सिर्फ बोलचाल हो सकता है:

  1. साझा ऑब्जेक्ट: एक लाइब्रेरी जो प्रोग्राम प्रारंभ होने पर प्रोग्राम में स्वचालित रूप से जुड़ा हुआ है, और एक स्टैंडअलोन फ़ाइल के रूप में मौजूद है। लाइब्रेरी को संकलन समय में लिंकिंग सूची में शामिल किया गया है (यानी: एलडीओपीटीएस + = - lmylib mylib.so नामक लाइब्रेरी फ़ाइल के लिए)। पुस्तकालय संकलन समय पर मौजूद होना चाहिए, और जब एप्लिकेशन शुरू होता है।
  2. स्टेटिक लाइब्रेरी: एक लाइब्रेरी जो वास्तविक प्रोग्राम में एक ही (बड़े) एप्लिकेशन के लिए बिल्ड समय पर विलय हो जाती है जिसमें एप्लिकेशन कोड और लाइब्रेरी कोड होता है जो प्रोग्राम बनने पर स्वचालित रूप से प्रोग्राम में जुड़ा होता है, और अंतिम बाइनरी दोनों मुख्य कार्यक्रम और लाइब्रेरी स्वयं एक स्टैंडअलोन बाइनरी फ़ाइल के रूप में मौजूद है। पुस्तकालय संकलन समय पर लिंकिंग सूची में शामिल है (यानी: एलडीओपीटीएस + = - lmylib mylib.a नामक लाइब्रेरी फ़ाइल के लिए)। पुस्तकालय संकलन समय पर मौजूद होना चाहिए।
  3. डीएलएल: अनिवार्य रूप से एक साझा वस्तु के समान, लेकिन संकलन समय पर लिंकिंग सूची में शामिल होने के बजाय, लाइब्रेरी को dlopen() / dlsym() कमांड के माध्यम से लोड किया जाता है ताकि लाइब्रेरी को बिल्ड समय पर उपस्थित होने की आवश्यकता न हो संकलन करने के लिए कार्यक्रम। साथ ही, लाइब्रेरी को एप्लिकेशन स्टार्टअप या संकलन समय पर उपस्थित होने की आवश्यकता नहीं है , क्योंकि इस समय केवल dlsym / dlsym कॉल किए जाने की आवश्यकता होती है।
  4. साझा पुरालेख: अनिवार्य रूप से एक स्थिर पुस्तकालय के समान, लेकिन "निर्यात-साझा" और "-एफपीआईसी" झंडे के साथ संकलित किया गया है। लाइब्रेरी को संकलन समय में लिंकिंग सूची में शामिल किया गया है (यानी: एलडीओपीटीएस + = - lmylib S लाइब्रेरी फाइल के लिए mylib S । ए)। दोनों के बीच भेद यह है कि यदि कोई साझा ऑब्जेक्ट या डीएलएल साझा संग्रह को अपने कोड में स्थिर रूप से लिंक करना चाहता है और अन्य प्रोग्रामों के लिए उपलब्ध साझा ऑब्जेक्ट में फ़ंक्शंस को केवल इनका उपयोग करने के बजाय, यह अतिरिक्त ध्वज आवश्यक है डीएलएल के लिए आंतरिक। यह उस मामले में उपयोगी होता है जब कोई आपको एक स्थिर पुस्तकालय प्रदान करता है, और आप इसे एसओ के रूप में पुन: पैकेज करना चाहते हैं। पुस्तकालय संकलन समय पर मौजूद होना चाहिए।

अतिरिक्त अद्यतन

" DLL " और " shared library " के बीच भेद उस कंपनी में केवल एक (आलसी, गलत) बोलचालवाद था जिस पर मैंने काम किया था (विंडोज डेवलपर्स को लिनक्स विकास में बदलाव करने के लिए मजबूर होना पड़ा, और शब्द फंस गया), वर्णनों का पालन करते हुए ऊपर उल्लेख किया गया।

इसके अतिरिक्त, लाइब्रेरी नाम के पीछे पीछे " S " शाब्दिक, "साझा अभिलेखागार" के मामले में उस कंपनी में इस्तेमाल किया जाने वाला एक सम्मेलन था, न कि सामान्य रूप से उद्योग में।


आप उस स्थिर फाइलों में सही हैं, लिंक-टाइम पर एप्लिकेशन पर प्रतिलिपि बनाई गई हैं, और साझा की गई फाइलें लिंक समय पर सत्यापित हैं और रनटाइम पर लोड की गई हैं।

डलोपेन कॉल केवल साझा ऑब्जेक्ट्स के लिए नहीं है, यदि एप्लिकेशन अपनी तरफ से रनटाइम पर ऐसा करना चाहता है, अन्यथा एप्लिकेशन प्रारंभ होने पर साझा ऑब्जेक्ट स्वचालित रूप से लोड हो जाते हैं। डीएलएलएस और .so एक ही बात है। dlopen प्रक्रियाओं के लिए और भी बढ़िया गतिशील लोडिंग क्षमताओं को जोड़ने के लिए मौजूद है। आपको DLLs को खोलने / उपयोग करने के लिए खुद को dlopen का उपयोग नहीं करना है, जो एप्लिकेशन स्टार्टअप पर भी होता है।


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

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

विंडोज़ (.dll) पर एक गतिशील लिंक लाइब्रेरी लिनक्स पर एक साझा लाइब्रेरी (.so) की तरह है लेकिन ओएस (विंडोज बनाम लिनक्स) से संबंधित दो कार्यान्वयन के बीच कुछ अंतर हैं:

एक डीएलएल दो प्रकार के कार्यों को परिभाषित कर सकता है: निर्यात और आंतरिक। निर्यात किए गए कार्यों को अन्य मॉड्यूल के साथ-साथ डीएलएल के भीतर से जाना जाता है जहां उन्हें परिभाषित किया जाता है। आंतरिक कार्यों को आम तौर पर डीएलएल के भीतर से बुलाया जाता है जहां उन्हें परिभाषित किया जाता है।

लिनक्स पर एक एसओ लाइब्रेरी को निर्यात योग्य प्रतीकों को इंगित करने के लिए विशेष निर्यात विवरण की आवश्यकता नहीं है, क्योंकि सभी प्रतीकों एक पूछताछ प्रक्रिया के लिए उपलब्ध हैं।


मैंने हमेशा सोचा है कि डीएलएल और साझा ऑब्जेक्ट्स एक ही चीज़ के लिए अलग-अलग शब्द हैं - विंडोज़ उन्हें डीएलएल कहते हैं, जबकि यूनिक्स सिस्टम पर वे ऑब्जेक्ट्स साझा करते हैं, सामान्य शब्द - गतिशील रूप से लिंक्ड लाइब्रेरी - दोनों को कवर करना (यहां तक ​​कि फ़ंक्शन यूनिक्स पर एक .so खोलें जिसे 'गतिशील पुस्तकालय' के बाद dlopen() कहा जाता है)।

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

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





linker