लिंकर (कंप्यूटिंग): Difference between revisions
No edit summary |
No edit summary |
||
| Line 2: | Line 2: | ||
[[File:Linker.svg|thumb|लिंक करने की प्रक्रिया का एक उदाहरण। ऑब्जेक्ट फाइल्स और [[स्थिर पुस्तकालय]] को एक नई लाइब्रेरी या निष्पादन में असेंबल किया जाता है।]] | [[File:Linker.svg|thumb|लिंक करने की प्रक्रिया का एक उदाहरण। ऑब्जेक्ट फाइल्स और [[स्थिर पुस्तकालय]] को एक नई लाइब्रेरी या निष्पादन में असेंबल किया जाता है।]] | ||
[[कम्प्यूटिंग]] में, एक लिंकर या लिंक संपादक एक कंप्यूटर | [[कम्प्यूटिंग]] में, एक '''लिंकर''' या लिंक संपादक एक कंप्यूटर सिस्टम सॉफ्टवेयर है जो एक या एक से अधिक ऑब्जेक्ट फ़ाइल ([[संकलक]] या असेंबलर (कंप्यूटिंग) द्वारा उत्पन्न) लेता है और उन्हें एक [[निष्पादन]] योग्य फ़ाइल, [[पुस्तकालय (कम्प्यूटिंग)]] फ़ाइल, या अन्य ऑब्जेक्ट फ़ाइल में जोड़ता है। एक सरल संस्करण जो अपने इनपुट/आउटपुट को सीधे मेमोरी में लिखता है, उसे ''लोडर'' कहा जाता है, यद्यपि [[लोडर (कंप्यूटिंग)]] को अधिकतर एक अलग प्रक्रिया माना जाता है।<ref name="IBM_1972"/><ref name="Barron_1978_Consolidator"/> | ||
== अवलोकन == | == अवलोकन == | ||
कंप्यूटर प्रोग्राम अधिकतर कई भागों या मॉड्यूल से बने होते हैं, इन भागों/मॉड्यूल को एक | कंप्यूटर प्रोग्राम अधिकतर कई भागों या मॉड्यूल से बने होते हैं, इन भागों/मॉड्यूल को एक ऑब्जेक्ट फ़ाइल के भीतर समाहित करने की आवश्यकता नहीं है और ऐसे विषयों में [[डिबग प्रतीक]] के माध्यम से एक दूसरे मॉड्यूल में पतों के रूप में एक दूसरे को संदर्भित करते हैं, जो निष्पादन के लिए लिंक किए जाने पर मेमोरी पतों में मैप किए जाते हैं। | ||
जबकि लिंकिंग की प्रक्रिया अंततः इन स्वतंत्र भागों को संयोजित करने के लिए होती है, स्रोत कोड-स्तर पर उन्हें अलग से विकसित करने के कई अच्छे कारण हैं। इन कारणों में एक अखंड कोडबेस पर कई छोटे टुकड़ों को व्यवस्थित करने में सरलता और प्रत्येक व्यक्तिगत टुकड़े के उद्देश्य और उत्तरदायित्व को बेहतर ढंग से परिभाषित करने की क्षमता सम्मलित है, जो [[सॉफ़्टवेयर वास्तुशिल्प]] में जटिलता के प्रबंधन और दीर्घकालिक स्थिरता को बढ़ाने के लिए आवश्यक है। | जबकि लिंकिंग की प्रक्रिया अंततः इन स्वतंत्र भागों को संयोजित करने के लिए होती है, स्रोत कोड-स्तर पर उन्हें अलग से विकसित करने के कई अच्छे कारण हैं। इन कारणों में एक अखंड कोडबेस पर कई छोटे टुकड़ों को व्यवस्थित करने में सरलता और प्रत्येक व्यक्तिगत टुकड़े के उद्देश्य और उत्तरदायित्व को बेहतर ढंग से परिभाषित करने की क्षमता सम्मलित है, जो [[सॉफ़्टवेयर वास्तुशिल्प]] में जटिलता के प्रबंधन और दीर्घकालिक स्थिरता को बढ़ाने के लिए आवश्यक है। | ||
बहुधा, एक | बहुधा, एक ऑब्जेक्ट फ़ाइल में तीन प्रकार के प्रतीक हो सकते हैं: | ||
* बाहरी प्रतीक, जो इसे अन्य मॉड्यूलों द्वारा बुलाए जाने की अनुमति देते हैं, उन्हें सार्वजनिक प्रतीकों के रूप में जाना जाता है। | * बाहरी प्रतीक, जो इसे अन्य मॉड्यूलों द्वारा बुलाए जाने की अनुमति देते हैं, उन्हें सार्वजनिक प्रतीकों के रूप में जाना जाता है। | ||
* अपरिभाषित "बाहरी" प्रतीक, जो अन्य मॉड्यूल को संदर्भित करते हैं जहां इन प्रतीकों को परिभाषित किया गया है। | * अपरिभाषित "बाहरी" प्रतीक, जो अन्य मॉड्यूल को संदर्भित करते हैं जहां इन प्रतीकों को परिभाषित किया गया है। | ||
* स्थानीय प्रतीकों, जिन्हें आंतरिक रूप से [[स्थानांतरण (कंप्यूटर विज्ञान)]] की सुविधा के लिए | * स्थानीय प्रतीकों, जिन्हें आंतरिक रूप से [[स्थानांतरण (कंप्यूटर विज्ञान)]] की सुविधा के लिए ऑब्जेक्ट फ़ाइल के भीतर उपयोग किया जाता है। | ||
कंपाइलरों के लिए, प्रत्येक | कंपाइलरों के लिए, प्रत्येक ऑब्जेक्ट फ़ाइल एक इनपुट स्रोत कोड फ़ाइल को संकलित करने का परिणाम है। जब एक प्रोग्राम में कई अधिकांश ऑब्जेक्ट फ़ाइल होती हैं, तो प्रतीकों को हल करने के साथ-साथ, लिंकर इन फ़ाइलों को एक एकीकृत निष्पादन योग्य प्रोग्राम में जोड़ता है। | ||
लिंकर्स, लाइब्रेरी (कंप्यूटिंग) या [[क्रम पुस्तकालय]] नामक संग्रह से ऑब्जेक्ट ले सकते हैं। अधिकांश लिंकर्स आउटपुट में पूरी लाइब्रेरी को सम्मिलित नहीं करते हैं, उनमें केवल फाइलें सम्मिलित होती है{{clarify|date=March 2020}} जो अन्य ऑब्जेक्ट फाइलों या पुस्तकालयों द्वारा संदर्भित हैं। लाइब्रेरी लिंकिंग इस प्रकार एक पुनरावृत्त प्रक्रिया हो सकती है, जिसमें कुछ संदर्भित मॉड्यूल को जोड़ने के लिए अतिरिक्त मॉड्यूल की आवश्यकता होती है, और इसी तरह पुस्तकालय विविध उद्देश्यों के लिए निहित हैं, और एक या एक से अधिक पुस्तकालय प्रणाली बहुधा डिफ़ॉल्ट रूप में जुड़े होते हैं। | लिंकर्स, लाइब्रेरी (कंप्यूटिंग) या [[क्रम पुस्तकालय]] नामक संग्रह से ऑब्जेक्ट ले सकते हैं। अधिकांश लिंकर्स आउटपुट में पूरी लाइब्रेरी को सम्मिलित नहीं करते हैं, उनमें केवल फाइलें सम्मिलित होती है{{clarify|date=March 2020}} जो अन्य ऑब्जेक्ट फाइलों या पुस्तकालयों द्वारा संदर्भित हैं। लाइब्रेरी लिंकिंग इस प्रकार एक पुनरावृत्त प्रक्रिया हो सकती है, जिसमें कुछ संदर्भित मॉड्यूल को जोड़ने के लिए अतिरिक्त मॉड्यूल की आवश्यकता होती है, और इसी तरह पुस्तकालय विविध उद्देश्यों के लिए निहित हैं, और एक या एक से अधिक पुस्तकालय प्रणाली बहुधा डिफ़ॉल्ट रूप में जुड़े होते हैं। | ||
| Line 20: | Line 20: | ||
लिंकर प्रोग्राम के [[आधार पता]] स्पेस में ऑब्जेक्ट्स को व्यवस्थित करने का भी ध्यान रखता है। इसमें कोड को स्थानांतरित करना सम्मिलित हो सकता है जो एक विशिष्ट आधार पते को दूसरे आधार पर मानता है। चूंकि एक कंपाइलर संभव ही कभी जानता है कि कोई ऑब्जेक्ट कहां रहेगा, यह उसे अधिकतर एक निश्चित आधार स्थान (उदाहरण के लिए, [[शून्य आधार]]) पर मानता है। मशीन कोड को स्थानांतरित करने में पूर्ण छलांग, लोड और स्टोर का पुन: लक्ष्यीकरण करना सम्मिलित हो सकता है। | लिंकर प्रोग्राम के [[आधार पता]] स्पेस में ऑब्जेक्ट्स को व्यवस्थित करने का भी ध्यान रखता है। इसमें कोड को स्थानांतरित करना सम्मिलित हो सकता है जो एक विशिष्ट आधार पते को दूसरे आधार पर मानता है। चूंकि एक कंपाइलर संभव ही कभी जानता है कि कोई ऑब्जेक्ट कहां रहेगा, यह उसे अधिकतर एक निश्चित आधार स्थान (उदाहरण के लिए, [[शून्य आधार]]) पर मानता है। मशीन कोड को स्थानांतरित करने में पूर्ण छलांग, लोड और स्टोर का पुन: लक्ष्यीकरण करना सम्मिलित हो सकता है। | ||
लिंकर द्वारा निष्पादन योग्य आउटपुट को एक और स्थानांतरण पास की आवश्यकता हो सकती है जब इसे अंत में मेमोरी में लोड किया जाता है (निष्पादन से ठीक पहले)। तो यह पास बहुधा [[अप्रत्यक्ष स्मृति]] प्रदान करने वाले [[कम्पुटर के वो भाग जिसे छूकर मेहसूस किया जा सके]] पर छोड़ दिया जाता है। प्रत्येक प्रोग्राम को अपने स्वयं के [[पता स्थान]] में रखा जाता है, इसलिए कोई विरोध नहीं होता है, भले ही सभी प्रोग्राम एक ही आधार पते पर लोड हों। निष्पादन योग्य का [[स्थिति स्वतंत्र]] निष्पादन योग्य होने पर भी यह पास छोड़ा जा सकता है। | लिंकर द्वारा निष्पादन योग्य आउटपुट को एक और स्थानांतरण पास की आवश्यकता हो सकती है जब इसे अंत में मेमोरी में लोड किया जाता है (निष्पादन से ठीक पहले)। तो यह पास बहुधा [[अप्रत्यक्ष स्मृति|अप्रत्यक्ष मेमोरी]] प्रदान करने वाले [[कम्पुटर के वो भाग जिसे छूकर मेहसूस किया जा सके]] पर छोड़ दिया जाता है। प्रत्येक प्रोग्राम को अपने स्वयं के [[पता स्थान]] में रखा जाता है, इसलिए कोई विरोध नहीं होता है, भले ही सभी प्रोग्राम एक ही आधार पते पर लोड हों। निष्पादन योग्य का [[स्थिति स्वतंत्र]] निष्पादन योग्य होने पर भी यह पास छोड़ा जा सकता है। | ||
सिंट्रान III जैसे कुछ [[यूनिक्स]] प्रकारों पर, एक लिंकर (ऑब्जेक्ट फ़ाइलों को एक प्रोग्राम में असेंबल करना) द्वारा की जाने वाली प्रक्रिया को लोडर (कंप्यूटिंग) कहा जाता था (जैसा कि फ़ाइल पर निष्पादन योग्य कोड लोड करने में होता है)।<ref name="BRF_1984" />इसके अतिरिक्त, कुछ ऑपरेटिंग सिस्टम में, एक ही प्रोग्राम एक प्रोग्राम ([[गतिशील जुड़ाव]]) को जोड़ने और लोड करने के दोनों कार्यों को नियंत्रण करता है। | सिंट्रान III जैसे कुछ [[यूनिक्स]] प्रकारों पर, एक लिंकर (ऑब्जेक्ट फ़ाइलों को एक प्रोग्राम में असेंबल करना) द्वारा की जाने वाली प्रक्रिया को लोडर (कंप्यूटिंग) कहा जाता था (जैसा कि फ़ाइल पर निष्पादन योग्य कोड लोड करने में होता है)।<ref name="BRF_1984" />इसके अतिरिक्त, कुछ ऑपरेटिंग सिस्टम में, एक ही प्रोग्राम एक प्रोग्राम ([[गतिशील जुड़ाव]]) को जोड़ने और लोड करने के दोनों कार्यों को नियंत्रण करता है। | ||
== डायनेमिक लिंकिंग == | == डायनेमिक लिंकिंग == | ||
{{See also|गतिशील लिंकर}} | {{See also|गतिशील लिंकर}} | ||
कई [[ऑपरेटिंग सिस्टम]] वातावरण डायनेमिक लिंकिंग की अनुमति देते हैं, और कुछ अपरिभाषित प्रतीकों के संकल्प को तब तक रोकते हैं जब तक कि कोई प्रोग्राम नहीं चलाया जाता है। इसका अर्थ है कि निष्पादन योग्य कोड में अभी भी अपरिभाषित प्रतीक हैं, साथ ही | कई [[ऑपरेटिंग सिस्टम]] वातावरण डायनेमिक लिंकिंग की अनुमति देते हैं, और कुछ अपरिभाषित प्रतीकों के संकल्प को तब तक रोकते हैं जब तक कि कोई प्रोग्राम नहीं चलाया जाता है। इसका अर्थ है कि निष्पादन योग्य कोड में अभी भी अपरिभाषित प्रतीक हैं, साथ ही ऑब्जेक्टओं या पुस्तकालयों की एक सूची है जो इनके लिए परिभाषा प्रदान करेगी। प्रोग्राम को लोड करने से ये ऑब्जेक्ट/लाइब्रेरी भी लोड होंगे, और अंतिम लिंकिंग निष्पादित करेंगे। | ||
यह दृष्टिकोण दो लाभ प्रदान करता है: | यह दृष्टिकोण दो लाभ प्रदान करता है: | ||
| Line 42: | Line 42: | ||
स्टेटिक लिंकिंग प्रोग्राम में उपयोग किए जाने वाले सभी लाइब्रेरी नियमित निष्पादन योग्य छवि में कॉपी करने वाले लिंकर का परिणाम है। डायनेमिक लिंकिंग की तुलना में इसके लिए अधिक डिस्क स्थान और मेमोरी की आवश्यकता हो सकती है, लेकिन यह अधिक पोर्टेबल है, क्योंकि इसे उस सिस्टम पर [[डायनेमिक-लिंक लाइब्रेरी]] की उपस्थिति की आवश्यकता नहीं है जहां यह चलता है। स्टेटिक लिंकिंग डीएलएल नरक को भी रोकता है, क्योंकि प्रत्येक प्रोग्राम में लाइब्रेरी निर्धारित विधि के ठीक उसी संस्करण को सम्मिलित किया जाता है जिसकी उसे आवश्यकता होती है, जिसमें अन्य कार्यक्रमों के साथ कोई विरोध नहीं होता है। यदि कोई प्रोग्राम लाइब्रेरी से केवल कुछ परिभाषित विधियों का उपयोग करता है, तो उसे संपूर्ण लाइब्रेरी को स्थापित करने की आवश्यकता नहीं होती है। | स्टेटिक लिंकिंग प्रोग्राम में उपयोग किए जाने वाले सभी लाइब्रेरी नियमित निष्पादन योग्य छवि में कॉपी करने वाले लिंकर का परिणाम है। डायनेमिक लिंकिंग की तुलना में इसके लिए अधिक डिस्क स्थान और मेमोरी की आवश्यकता हो सकती है, लेकिन यह अधिक पोर्टेबल है, क्योंकि इसे उस सिस्टम पर [[डायनेमिक-लिंक लाइब्रेरी]] की उपस्थिति की आवश्यकता नहीं है जहां यह चलता है। स्टेटिक लिंकिंग डीएलएल नरक को भी रोकता है, क्योंकि प्रत्येक प्रोग्राम में लाइब्रेरी निर्धारित विधि के ठीक उसी संस्करण को सम्मिलित किया जाता है जिसकी उसे आवश्यकता होती है, जिसमें अन्य कार्यक्रमों के साथ कोई विरोध नहीं होता है। यदि कोई प्रोग्राम लाइब्रेरी से केवल कुछ परिभाषित विधियों का उपयोग करता है, तो उसे संपूर्ण लाइब्रेरी को स्थापित करने की आवश्यकता नहीं होती है। | ||
== {{Anchor|Relaxation|Jump-sizing}}स्थान परिवर्तन == | == {{Anchor|Relaxation|Jump-sizing}}स्थान परिवर्तन == | ||
चूंकि कंपाइलर के पास अंतिम आउटपुट में ऑब्जेक्ट्स के विन्यास के बारे में कोई जानकारी नहीं है, अतः यह छोटे या अधिक कुशल निर्देशों का लाभ नहीं उठा सकता है जो किसी अन्य ऑब्जेक्ट के पते पर आवश्यकता रखता है। उदाहरण के लिए, एक जंप निर्देश एक पूर्ण पते या वर्तमान स्थान से कमी को पूरी करना का संदर्भ दे सकता है, और इस कमी को लक्ष्य की दूरी के आधार पर अलग-अलग लंबाई के साथ व्यक्त किया जा सकता है। सबसे पहले रूढ़िवादी निर्देश (बहुधा प्लेटफॉर्म के आधार पर सबसे बड़ा सापेक्ष या पूर्ण संस्करण) उत्पन्न करके और विश्राम संकेत जोड़कर, अंतिम लिंक के समय छोटे या अधिक कुशल निर्देशों को प्रतिस्थापित करना संभव है। जंप अनुकूलतम के संबंध में इसे स्वचालित जंप-साइज़िंग भी कहा जाता है।<ref name="Salomon_1992"/> यह चरण केवल सभी इनपुट ऑब्जेक्ट्स को पढ़ने और अस्थायी पते नियुक्त करने के पश्चात ही किया जा सकता है, लिंकर छूट पास बाद में पतों को पुन: नियुक्त करता है, जो बदले में अधिक संभावित छूट देने की अनुमति दे सकता है। सामान्यतः प्रतिस्थापित अनुक्रम छोटे होते हैं, जो इस प्रक्रिया को | चूंकि कंपाइलर के पास अंतिम आउटपुट में ऑब्जेक्ट्स के विन्यास के बारे में कोई जानकारी नहीं है, अतः यह छोटे या अधिक कुशल निर्देशों का लाभ नहीं उठा सकता है जो किसी अन्य ऑब्जेक्ट के पते पर आवश्यकता रखता है। उदाहरण के लिए, एक जंप निर्देश एक पूर्ण पते या वर्तमान स्थान से कमी को पूरी करना का संदर्भ दे सकता है, और इस कमी को लक्ष्य की दूरी के आधार पर अलग-अलग लंबाई के साथ व्यक्त किया जा सकता है। सबसे पहले रूढ़िवादी निर्देश (बहुधा प्लेटफॉर्म के आधार पर सबसे बड़ा सापेक्ष या पूर्ण संस्करण) उत्पन्न करके और विश्राम संकेत जोड़कर, अंतिम लिंक के समय छोटे या अधिक कुशल निर्देशों को प्रतिस्थापित करना संभव है। जंप अनुकूलतम के संबंध में इसे स्वचालित जंप-साइज़िंग भी कहा जाता है।<ref name="Salomon_1992"/> यह चरण केवल सभी इनपुट ऑब्जेक्ट्स को पढ़ने और अस्थायी पते नियुक्त करने के पश्चात ही किया जा सकता है, लिंकर छूट पास बाद में पतों को पुन: नियुक्त करता है, जो बदले में अधिक संभावित छूट देने की अनुमति दे सकता है। सामान्यतः प्रतिस्थापित अनुक्रम छोटे होते हैं, जो इस प्रक्रिया को ऑब्जेक्टओं के एक निश्चित क्रम को देखते हुए सदैव सर्वोत्तम समाधान पर अभिसरण करने की अनुमति देता है, यदि ऐसा नहीं होता है, तो छूट संघर्ष कर सकती हैं, और तब लिंकर को किसी भी विकल्प के लाभों को जांचना होगा। | ||
जबकि निर्देश छूट अधिकतर लिंक-टाइम पर होती है, संकलन-समय पर अनुकूलन प्रक्रिया के हिस्से के रूप में आंतरिक-मॉड्यूल छूट पहले से ही हो सकती है। कुछ स्थितियों में, स्थानांतरण प्रक्रिया के भाग के रूप में लोड-समय पर विश्राम भी हो सकता है या गतिशील मृत-कोड उन्मूलन तकनीकों के साथ संयुक्त हो सकता है। | जबकि निर्देश छूट अधिकतर लिंक-टाइम पर होती है, संकलन-समय पर अनुकूलन प्रक्रिया के हिस्से के रूप में आंतरिक-मॉड्यूल छूट पहले से ही हो सकती है। कुछ स्थितियों में, स्थानांतरण प्रक्रिया के भाग के रूप में लोड-समय पर विश्राम भी हो सकता है या गतिशील मृत-कोड उन्मूलन तकनीकों के साथ संयुक्त हो सकता है। | ||
| Line 113: | Line 113: | ||
* [https://lld.llvm.org/ एलएलडी - एलएलवीएम लिंकर] | * [https://lld.llvm.org/ एलएलडी - एलएलवीएम लिंकर] | ||
* {{man|1|ld|die.net|जीएनयू लिंकर}} | * {{man|1|ld|die.net|जीएनयू लिंकर}} | ||
{{Authority control}} | {{Authority control}} | ||
Latest revision as of 17:17, 12 September 2023
कम्प्यूटिंग में, एक लिंकर या लिंक संपादक एक कंप्यूटर सिस्टम सॉफ्टवेयर है जो एक या एक से अधिक ऑब्जेक्ट फ़ाइल (संकलक या असेंबलर (कंप्यूटिंग) द्वारा उत्पन्न) लेता है और उन्हें एक निष्पादन योग्य फ़ाइल, पुस्तकालय (कम्प्यूटिंग) फ़ाइल, या अन्य ऑब्जेक्ट फ़ाइल में जोड़ता है। एक सरल संस्करण जो अपने इनपुट/आउटपुट को सीधे मेमोरी में लिखता है, उसे लोडर कहा जाता है, यद्यपि लोडर (कंप्यूटिंग) को अधिकतर एक अलग प्रक्रिया माना जाता है।[1][2]
अवलोकन
कंप्यूटर प्रोग्राम अधिकतर कई भागों या मॉड्यूल से बने होते हैं, इन भागों/मॉड्यूल को एक ऑब्जेक्ट फ़ाइल के भीतर समाहित करने की आवश्यकता नहीं है और ऐसे विषयों में डिबग प्रतीक के माध्यम से एक दूसरे मॉड्यूल में पतों के रूप में एक दूसरे को संदर्भित करते हैं, जो निष्पादन के लिए लिंक किए जाने पर मेमोरी पतों में मैप किए जाते हैं।
जबकि लिंकिंग की प्रक्रिया अंततः इन स्वतंत्र भागों को संयोजित करने के लिए होती है, स्रोत कोड-स्तर पर उन्हें अलग से विकसित करने के कई अच्छे कारण हैं। इन कारणों में एक अखंड कोडबेस पर कई छोटे टुकड़ों को व्यवस्थित करने में सरलता और प्रत्येक व्यक्तिगत टुकड़े के उद्देश्य और उत्तरदायित्व को बेहतर ढंग से परिभाषित करने की क्षमता सम्मलित है, जो सॉफ़्टवेयर वास्तुशिल्प में जटिलता के प्रबंधन और दीर्घकालिक स्थिरता को बढ़ाने के लिए आवश्यक है।
बहुधा, एक ऑब्जेक्ट फ़ाइल में तीन प्रकार के प्रतीक हो सकते हैं:
- बाहरी प्रतीक, जो इसे अन्य मॉड्यूलों द्वारा बुलाए जाने की अनुमति देते हैं, उन्हें सार्वजनिक प्रतीकों के रूप में जाना जाता है।
- अपरिभाषित "बाहरी" प्रतीक, जो अन्य मॉड्यूल को संदर्भित करते हैं जहां इन प्रतीकों को परिभाषित किया गया है।
- स्थानीय प्रतीकों, जिन्हें आंतरिक रूप से स्थानांतरण (कंप्यूटर विज्ञान) की सुविधा के लिए ऑब्जेक्ट फ़ाइल के भीतर उपयोग किया जाता है।
कंपाइलरों के लिए, प्रत्येक ऑब्जेक्ट फ़ाइल एक इनपुट स्रोत कोड फ़ाइल को संकलित करने का परिणाम है। जब एक प्रोग्राम में कई अधिकांश ऑब्जेक्ट फ़ाइल होती हैं, तो प्रतीकों को हल करने के साथ-साथ, लिंकर इन फ़ाइलों को एक एकीकृत निष्पादन योग्य प्रोग्राम में जोड़ता है।
लिंकर्स, लाइब्रेरी (कंप्यूटिंग) या क्रम पुस्तकालय नामक संग्रह से ऑब्जेक्ट ले सकते हैं। अधिकांश लिंकर्स आउटपुट में पूरी लाइब्रेरी को सम्मिलित नहीं करते हैं, उनमें केवल फाइलें सम्मिलित होती है[clarification needed] जो अन्य ऑब्जेक्ट फाइलों या पुस्तकालयों द्वारा संदर्भित हैं। लाइब्रेरी लिंकिंग इस प्रकार एक पुनरावृत्त प्रक्रिया हो सकती है, जिसमें कुछ संदर्भित मॉड्यूल को जोड़ने के लिए अतिरिक्त मॉड्यूल की आवश्यकता होती है, और इसी तरह पुस्तकालय विविध उद्देश्यों के लिए निहित हैं, और एक या एक से अधिक पुस्तकालय प्रणाली बहुधा डिफ़ॉल्ट रूप में जुड़े होते हैं।
लिंकर प्रोग्राम के आधार पता स्पेस में ऑब्जेक्ट्स को व्यवस्थित करने का भी ध्यान रखता है। इसमें कोड को स्थानांतरित करना सम्मिलित हो सकता है जो एक विशिष्ट आधार पते को दूसरे आधार पर मानता है। चूंकि एक कंपाइलर संभव ही कभी जानता है कि कोई ऑब्जेक्ट कहां रहेगा, यह उसे अधिकतर एक निश्चित आधार स्थान (उदाहरण के लिए, शून्य आधार) पर मानता है। मशीन कोड को स्थानांतरित करने में पूर्ण छलांग, लोड और स्टोर का पुन: लक्ष्यीकरण करना सम्मिलित हो सकता है।
लिंकर द्वारा निष्पादन योग्य आउटपुट को एक और स्थानांतरण पास की आवश्यकता हो सकती है जब इसे अंत में मेमोरी में लोड किया जाता है (निष्पादन से ठीक पहले)। तो यह पास बहुधा अप्रत्यक्ष मेमोरी प्रदान करने वाले कम्पुटर के वो भाग जिसे छूकर मेहसूस किया जा सके पर छोड़ दिया जाता है। प्रत्येक प्रोग्राम को अपने स्वयं के पता स्थान में रखा जाता है, इसलिए कोई विरोध नहीं होता है, भले ही सभी प्रोग्राम एक ही आधार पते पर लोड हों। निष्पादन योग्य का स्थिति स्वतंत्र निष्पादन योग्य होने पर भी यह पास छोड़ा जा सकता है।
सिंट्रान III जैसे कुछ यूनिक्स प्रकारों पर, एक लिंकर (ऑब्जेक्ट फ़ाइलों को एक प्रोग्राम में असेंबल करना) द्वारा की जाने वाली प्रक्रिया को लोडर (कंप्यूटिंग) कहा जाता था (जैसा कि फ़ाइल पर निष्पादन योग्य कोड लोड करने में होता है)।[3]इसके अतिरिक्त, कुछ ऑपरेटिंग सिस्टम में, एक ही प्रोग्राम एक प्रोग्राम (गतिशील जुड़ाव) को जोड़ने और लोड करने के दोनों कार्यों को नियंत्रण करता है।
डायनेमिक लिंकिंग
कई ऑपरेटिंग सिस्टम वातावरण डायनेमिक लिंकिंग की अनुमति देते हैं, और कुछ अपरिभाषित प्रतीकों के संकल्प को तब तक रोकते हैं जब तक कि कोई प्रोग्राम नहीं चलाया जाता है। इसका अर्थ है कि निष्पादन योग्य कोड में अभी भी अपरिभाषित प्रतीक हैं, साथ ही ऑब्जेक्टओं या पुस्तकालयों की एक सूची है जो इनके लिए परिभाषा प्रदान करेगी। प्रोग्राम को लोड करने से ये ऑब्जेक्ट/लाइब्रेरी भी लोड होंगे, और अंतिम लिंकिंग निष्पादित करेंगे।
यह दृष्टिकोण दो लाभ प्रदान करता है:
- अधिकतर उपयोग की जाने वाली लाइब्रेरी (उदाहरण के लिए मानक सिस्टम लाइब्रेरी) को प्रत्येक निष्पादन योग्य फ़ाइल में प्रतिलिपि की तरह उपयोग करने के अतिरिक्त केवल एक स्थान पर संग्रहीत करने की आवश्यकता होती है, इस प्रकार सीमित कंप्यूटर मेमोरी और डिस्क संग्रहण स्थान की बचत होती है।
- यदि लाइब्रेरी फ़ंक्शन में एक लाइब्रेरी को बदलकर एक त्रुटि को ठीक किया जाता है या कंप्यूटर के प्रदर्शन में सुधार किया जाता है, तो इसे गतिशील रूप से उपयोग करने वाले सभी प्रोग्रामों को पुनः आरंभ करने के पश्चात इस सुधार से लाभ होगा। स्टैटिक लिंकिंग द्वारा इस फ़ंक्शन को सम्मिलित करने वाले प्रोग्रामों को पहले फिर से लिंक करना होगा।
इसकी हानिया भी हैं:
- माइक्रोसॉफ्ट विंडोज़ प्लेटफॉर्म पर डायनामिक लिंक लाइब्रेरी नरक के रूप में जाना जाता है, यदि नया संस्करण सही ढंग से पिछड़ा संगत नहीं है, तो एक असंगत अपडेटेड लाइब्रेरी निष्पादनयोग्य को तोड़ देगी जो लाइब्रेरी के पिछले संस्करण के व्यवहार पर निर्भर करता है।
- एक प्रोग्राम को इसके द्वारा उपयोग किए जाने वाले पुस्तकालयों के साथ, एक पैकेज के रूप में प्रमाणित किया सकता है (उदाहरण के लिए शुद्धता, दस्तावेज़ीकरण आवश्यकताओं, या प्रदर्शन के रूप में), परन्तु ये तब नहीं किया जा सकता जब घटको को प्रतिस्थापित किया जा सकता है (यह महत्वपूर्ण सिस्टम में स्वचालित ओएस अपडेट के विपरीत भी तर्क देता है, दोनों ही विषयो में, ओएस और पुस्तकालय एक योग्य वातावरण का भाग बनते हैं)।
कंटेनरीकरण (कंप्यूटिंग) या ओएस-स्तरीय वर्चुअलाइजेशन वातावरण सिस्टम प्रशासक को इन व्यक्तिगत कारोबारी और विपक्षों को कम करने या व्यापार करने की अनुमति दे सकता है।
स्टेटिक लिंकिंग
स्टेटिक लिंकिंग प्रोग्राम में उपयोग किए जाने वाले सभी लाइब्रेरी नियमित निष्पादन योग्य छवि में कॉपी करने वाले लिंकर का परिणाम है। डायनेमिक लिंकिंग की तुलना में इसके लिए अधिक डिस्क स्थान और मेमोरी की आवश्यकता हो सकती है, लेकिन यह अधिक पोर्टेबल है, क्योंकि इसे उस सिस्टम पर डायनेमिक-लिंक लाइब्रेरी की उपस्थिति की आवश्यकता नहीं है जहां यह चलता है। स्टेटिक लिंकिंग डीएलएल नरक को भी रोकता है, क्योंकि प्रत्येक प्रोग्राम में लाइब्रेरी निर्धारित विधि के ठीक उसी संस्करण को सम्मिलित किया जाता है जिसकी उसे आवश्यकता होती है, जिसमें अन्य कार्यक्रमों के साथ कोई विरोध नहीं होता है। यदि कोई प्रोग्राम लाइब्रेरी से केवल कुछ परिभाषित विधियों का उपयोग करता है, तो उसे संपूर्ण लाइब्रेरी को स्थापित करने की आवश्यकता नहीं होती है।
स्थान परिवर्तन
चूंकि कंपाइलर के पास अंतिम आउटपुट में ऑब्जेक्ट्स के विन्यास के बारे में कोई जानकारी नहीं है, अतः यह छोटे या अधिक कुशल निर्देशों का लाभ नहीं उठा सकता है जो किसी अन्य ऑब्जेक्ट के पते पर आवश्यकता रखता है। उदाहरण के लिए, एक जंप निर्देश एक पूर्ण पते या वर्तमान स्थान से कमी को पूरी करना का संदर्भ दे सकता है, और इस कमी को लक्ष्य की दूरी के आधार पर अलग-अलग लंबाई के साथ व्यक्त किया जा सकता है। सबसे पहले रूढ़िवादी निर्देश (बहुधा प्लेटफॉर्म के आधार पर सबसे बड़ा सापेक्ष या पूर्ण संस्करण) उत्पन्न करके और विश्राम संकेत जोड़कर, अंतिम लिंक के समय छोटे या अधिक कुशल निर्देशों को प्रतिस्थापित करना संभव है। जंप अनुकूलतम के संबंध में इसे स्वचालित जंप-साइज़िंग भी कहा जाता है।[4] यह चरण केवल सभी इनपुट ऑब्जेक्ट्स को पढ़ने और अस्थायी पते नियुक्त करने के पश्चात ही किया जा सकता है, लिंकर छूट पास बाद में पतों को पुन: नियुक्त करता है, जो बदले में अधिक संभावित छूट देने की अनुमति दे सकता है। सामान्यतः प्रतिस्थापित अनुक्रम छोटे होते हैं, जो इस प्रक्रिया को ऑब्जेक्टओं के एक निश्चित क्रम को देखते हुए सदैव सर्वोत्तम समाधान पर अभिसरण करने की अनुमति देता है, यदि ऐसा नहीं होता है, तो छूट संघर्ष कर सकती हैं, और तब लिंकर को किसी भी विकल्प के लाभों को जांचना होगा।
जबकि निर्देश छूट अधिकतर लिंक-टाइम पर होती है, संकलन-समय पर अनुकूलन प्रक्रिया के हिस्से के रूप में आंतरिक-मॉड्यूल छूट पहले से ही हो सकती है। कुछ स्थितियों में, स्थानांतरण प्रक्रिया के भाग के रूप में लोड-समय पर विश्राम भी हो सकता है या गतिशील मृत-कोड उन्मूलन तकनीकों के साथ संयुक्त हो सकता है।
लिंकेज संपादक
आईबीएम सिस्टम/360 मेनफ़्रेम कंप्यूटर वातावरण में, जैसे कि ओएस/360, z/आर्किटेक्चर मेनफ्रेम के लिए z/ओएस सहित, इस प्रकार के प्रोग्राम को लिंकेज संपादक के रूप में जाना जाता है। जैसा कि नाम से पता चलता है कि एक लिंकेज संपादक में अलग-अलग प्रोग्राम के अनुभागों को जोड़ने, बदलने या हटाने की अनुमति देने की अतिरिक्त क्षमता होती है। OS/360 जैसे ऑपरेटिंग सिस्टम में निष्पादन योग्य लोड-मॉड्यूल के लिए प्रारूप होता है जिसमें प्रोग्राम के घटक अनुभागों के बारे में पूरक डेटा होता है, जिससे कि एक व्यक्तिगत प्रोग्राम अनुभाग को बदला जा सके, और प्रोग्राम के अन्य भागों को अपडेट किया जा सके , जिससे कि स्थानांतरित करने योग्य पते और अन्य संदर्भों को प्राप्त किया जा सके और प्रक्रिया के भाग के रूप में अन्य संदर्भों को लिंकेज संपादक द्वारा ठीक किया जा सकता है।।
इसका एक लाभ यह है कि यह सभी मध्यवर्ती फाइलों को रखे बिना, या बदले हुए प्रोग्राम अनुभागों को फिर से संकलित किए बिना एक प्रोग्राम को बनाए रखने की अनुमति देता है। यह प्रोग्राम अपडेट को छोटी फाइलों (मूल रूप से कार्ड डेक (कंप्यूटिंग) एस) के रूप में वितरित करने की अनुमति देता है, जिसमें केवल ऑब्जेक्ट मॉड्यूल को प्रतिस्थापित किया जाता है। ऐसी प्रणालियों में, ऑब्जेक्ट कोड 80-बाइट पंच-कार्ड छवियों के रूप और प्रारूप में होता है, जिससे कि उस माध्यम का उपयोग करके सिस्टम में अपडेट समक्ष किए जा सकें। ओएस/360 के बाद के रिलीज और बाद के सिस्टम में, अद्यतनों का पता लगाने के योग्य रिकॉर्ड बनाने के लिए, लोड-मॉड्यूल में घटक मॉड्यूल के संस्करणों के बारे में अतिरिक्त डेटा होता है। यह पहले से लिंक किए गए लोड मॉड्यूल से एक ओवरले (प्रोग्रामिंग) संरचना को जोड़ने, बदलने या हटाने की भी अनुमति देता है।
"लिंकेज संपादक" शब्द का अर्थ यह नहीं लगाया जाना चाहिए कि प्रोग्राम टेक्स्ट संपादक जैसे यूजर-पारस्परिक मोड में संचालित होता है। यह बैच-मोड निष्पादन के लिए अभिप्रेत है, उपयोगकर्ता द्वारा अनुक्रमिक रूप से संगठित फ़ाइलों, छिद्रित कार्ड, डायरेक्ट-एक्सेस स्टोरेज डिवाइस, या चुंबकीय टेप में संपादन आदेशों की आपूर्ति की जा रही है, और टेप अधिकतर ओएस की प्रारंभिक स्थापना के समय उपयोग किए जाते थे।
लिंकेज एडिटिंग ( आईबीएम नामकरण) या समेकन या संग्रह (इंटरनेशनल कंप्यूटर लिमिटेड नामकरण), लिंकेज संपादक या समेकनकर्ता के विभिन्न टुकड़ों को पुनर्स्थापन योग्य बाइनरी में संयोजित करने के कार्य को संदर्भित करता है, जबकि लक्ष्य पते पर एक पूर्ण बाइनरी में लोडिंग और स्थानांतरण को सामान्य रूप से एक अलग प्रयास माना जाता है।[2]
सामान्य कार्यान्वयन
यूनिक्स और यूनिक्स जैसी प्रणालियों पर, लिंकर को एलडी के रूप में जाना जाता है। एलडी नाम की उत्पत्ति लोडर और लिंक संपादक हैं। लिंकिंग की प्रक्रिया के समय अन्य कार्यक्रमों से बाहरी प्रतीकों को लोड करने की प्रक्रिया का वर्णन करने के लिए लोडर शब्द का उपयोग किया गया था।[5]
जीएनयू लिंकर
जीएनयू लिंकर (या जीएनयू एलडी) यूनिक्स कमांड एलडी का जीएनयू परियोजना के मुफ्त सॉफ्टवेयर का कार्यान्वयन है। जीएनयू एलडी लिंकर को चलाता है, जो एक सॉफ्टवेयर प्रोजेक्ट के संकलन के समय बनाई गई ऑब्जेक्ट फाइलों से निष्पादन योग्य फ़ाइल (या लाइब्रेरी) को बनाता है। लिंकिंग प्रक्रिया पर अधिक नियंत्रण रखने के लिए एक लिंकर स्क्रिप्ट जीएनयू एलडी को पास की जा सकती है। [6] जीएनयू लिंकर जीएनयू बाइनरी यूटिलिटीज (बिनुटिल्स) का भाग है। बिनुटिल्स में एलडी के दो संस्करण प्रदान किए गए हैं जिसमे एक पारंपरिक जीएनयू एलडी जो की बाइनरी फाइल डिस्क्रिप्टर लाइब्रेरी पर आधारित है, और दुसरा सुव्यवस्थित ईएलएफ-ओनली संस्करण जिसे सोना (लिंकर) कहा जाता है।
जीएनयू एलडी के कमांड-लाइन और लिंकर स्क्रिप्ट सिंटैक्स अधिकांश यूनिक्स जैसी दुनिया में वास्तविक मानक है। एलएलवीएम परियोजना के लिंकर, एलएलडी को ड्रॉप-इन संगत होने के लिए डिज़ाइन किया गया है, और सीधे जीएनयू कंपाइलर के साथ उपयोग किया जा सकता है। एक और ड्रॉप-इन रिप्लेसमेंट, मोल्ड, एक अत्यधिक समानांतर और तेज़ विकल्प है जो जीएनयू टूल द्वारा भी समर्थित है।
यह भी देखें
- बाइनरी फाइल डिस्क्रिप्टर लाइब्रेरी (libbfd)
- कंपाइल एंड गो सिस्टम
- डीएलएल नरक
- प्रत्यक्ष बंधन
- डायनेमिक बाइंडिंग (कंप्यूटिंग)
- गतिशील मृत कोड उन्मूलन
- गतिशील प्रेषण
- गतिशील पुस्तकालय
- गतिशील लिंकर
- गतिशील लोडिंग
- डायनामिक-लिंक लाइब्रेरी
- बाहरी चर
- पुस्तकालय (कम्प्यूटिंग)
- लोडर (कंप्यूटिंग)
- नाम सजावट
- प्रीलिंकिंग (प्रीबाइंडिंग)
- स्थानांतरण (कंप्यूटिंग)
- स्मार्ट लिंकिंग
- स्टेटिक लाइब्रेरी
- सोना (लिंकर)
संदर्भ
- ↑ आईबीएम ओएस लिंकेज संपादक और लोडर (PDF). आईबीएम कॉर्पोरेशन. 1972. Archived (PDF) from the original on 2020-03-06. Retrieved 2020-03-07.
- ↑ 2.0 2.1 Barron, David William (1978) [1971, 1969]. "5.7. Linkage editors and consolidators". Written at University of Southampton, Southampton, UK. In Floretin, J. John (ed.). असेंबलर और लोडर. कंप्यूटर मोनोग्राफ (3 ed.). New York, USA: Elsevier North-Holland Inc. pp. 65–66. ISBN 0-444-19462-2. LCCN 78-19961. (xii+100 pages)
- ↑ बीआरएफ-लिंकर उपयोगकर्ता मैनुअल. August 1984. ND-60.196.01.
- ↑ Salomon, David (February 1993) [1992]. "8.2.3 Automatic jump-sizing" (PDF). Written at California State University, Northridge, California, USA. In Chivers, Ian D. (ed.). असेंबलर और लोडर. कंप्यूटर और उनके अनुप्रयोगों में एलिस होरवुड श्रृंखला (1 ed.). चिसेस्टर, वेस्ट ससेक्स, यूके: Ellis Horwood Limited / Simon & Schuster International Group. pp. 237–238. ISBN 0-13-052564-2. Archived (PDF) from the original on 2020-03-23. Retrieved 2008-10-01. (xiv+294+4 pages)
- ↑ "1. ld". यूनिक्स प्रोग्रामर मैनुअल (6 ed.). May 1975.
- ↑ "जीएनयू बिनुटिल्स: लिंकर स्क्रिप्ट्स". 2018-07-18. Archived from the original on 2020-03-06. Retrieved 2019-01-18.
आगे की पढाई
- फ्रेजर, क्रिस्टोफर डब्ल्यू.; हैन्सन, डेविड आर. (April 1982). "A Machine Independent Linker". Software: Practice and Experience. John Wiley & Sons Ltd. 12 (4): 351–366. doi:10.1002/spe.4380120407. ISSN 1097-024X. S2CID 206508204.
- ऑपरेटिंग सिस्टम 360 - लिंकेज एडिटर (ई) - प्रोग्राम लॉजिक मैनुअल (PDF) (3 ed.). इंटरनेशनल बिजनेस मशीन कॉर्पोरेशन. 1969-07-23 [June 1967]. Program number 360S-ED-510. File No. S360-31. Form Y28-6610-2. Archived from the original (PDF) on 2007-10-01. Retrieved 2020-03-07.
- जोन्स, डगलस डब्ल्यू. (August 1983). "ऑब्जेक्ट कोड के रूप में असेंबली भाषा". सॉफ्टवेयर: अभ्यास और अनुभव. जॉन विली एंड संस लिमिटेड. 13 (8): 715–725. doi:10.1002/spe.4380130806. ISSN 1097-024X. S2CID 42995338.
- लेविन, जॉन आर. (2000) [October 1999]. लिंकर और लोडर. सॉफ्टवेयर इंजीनियरिंग और प्रोग्रामिंग में मॉर्गन कॉफ़मैन श्रृंखला (1 ed.). सैन फ्रांसिस्को, यूएसए: मॉर्गन कॉफ़मैन. ISBN 1-55860-496-0. OCLC 42413382. Archived from the original on 2012-12-05. Retrieved 2020-01-12. Code: [1][2] Errata: [3]
- प्रेशर, लियोन; व्हाइट, जॉन आर. (September 1972). "Linkers and Loaders" (PDF). ACM Computing Surveys. University of California, Santa Barbara, California, USA. 4 (3): 149–167. doi:10.1145/356603.356605. S2CID 5694671. Archived (PDF) from the original on 2020-03-07. Retrieved 2020-03-07. (19 pages)
- रैमसे, नॉर्मन (May 1996). "करींग द्वारा मशीन अनुदेशों को स्थानांतरित करना" (PDF). ACM SIGPLAN Notices. 31 (5): 226–236. doi:10.1145/249069.231429. Archived (PDF) from the original on 2020-05-18.
बाहरी कड़ियाँ
- इयान लांस जस्टिन की लिंकर्स ब्लॉग प्रविष्टियाँ
- लिंकर और लोडर, a लिनक्स जर्नल संदीप ग्रोवर का लेख
- असेंबली भाषा विकास के लिए मुफ़्त टूल का संपूर्ण संग्रह कहां से प्राप्त करें इसकी एक और सूची
- जीएनयू लिंकर मैनुअल
- एलएलडी - एलएलवीएम लिंकर
- : जीएनयू लिंकर – Linux User Commands Manual
