लिंकर शुरुआती गाइड

डेविड ड्रिस्डेल , लिंकर्स के लिए शुरुआती गाइड ( http://www.lurklurk.org/linkers/linkers.html )।

इस लेख का उद्देश्य सी और सी + + प्रोग्रामर्स को यह समझने में मदद करना है कि लिंकर क्या करता है। पिछले कुछ वर्षों में, मैंने इसे बड़ी संख्या में सहयोगियों को समझाया, और अंत में फैसला किया कि इस सामग्री को कागज में स्थानांतरित करने का समय था ताकि यह अधिक सुलभ हो जाए (और इसलिए मुझे इसे फिर से समझाने की ज़रूरत नहीं थी)। [मार्च २०० ९ अपडेट: विंडोज में लेआउट सुविधाओं के बारे में अतिरिक्त जानकारी, साथ ही साथ एक अधिक विस्तृत एक-परिभाषा नियम।

मुझे मदद के लिए संपर्क क्यों किया गया था इसका एक विशिष्ट उदाहरण निम्नलिखित लेआउट त्रुटि है:

g++ -o test1 test1a.o test1b.o test1a.o(.text+0x18): In function `main': : undefined reference to `findmax(int, int)' collect2: ld returned 1 exit status 

यदि आपकी प्रतिक्रिया 'शायद "सी" भूल गए हैं, "तो आप सबसे अधिक संभावना है कि इस लेख में दी गई सब कुछ जानते हैं।

सामग्री

• परिभाषाएँ: सी फ़ाइल में क्या है?
• सी कंपाइलर क्या करता है
• लिंकर क्या करता है: भाग 1
• ऑपरेटिंग सिस्टम क्या करता है?
• लिंकर क्या करता है: भाग 2
• चित्र को पूरक करने के लिए C ++
• गतिशील रूप से भरी हुई लाइब्रेरी
• इसके साथ ही

परिभाषाएँ: सी फ़ाइल में क्या है?

यह अध्याय C फ़ाइल के विभिन्न घटकों का एक संक्षिप्त अनुस्मारक है। यदि नीचे दी गई सूची में सब कुछ आपके लिए समझ में आता है, तो सबसे अधिक संभावना है कि आप इस अध्याय को छोड़ सकते हैं और सीधे अगले पर जा सकते हैं ।

पहले आपको एक घोषणा और एक परिभाषा के बीच के अंतर को समझने की आवश्यकता है। एक नाम एक कार्यान्वयन के साथ एक नाम को जोड़ता है, जो कोड या डेटा हो सकता है:

• एक चर की परिभाषा संकलक को स्मृति के एक निश्चित क्षेत्र को आरक्षित करने का कारण बनती है, संभवतः इसे एक निश्चित विशिष्ट मूल्य पर सेट करना है।
  
• फ़ंक्शन फ़ंक्शन इस फ़ंक्शन के लिए कोड उत्पन्न करने के लिए एक फ़ंक्शन परिभाषा का कारण बनता है
  

घोषणा संकलक को बताती है कि एक फ़ंक्शन या चर (एक विशिष्ट नाम के साथ) की परिभाषा कार्यक्रम में कहीं और मौजूद है, शायद एक अलग सी फ़ाइल में। (ध्यान दें कि परिभाषा भी एक घोषणा है - वास्तव में, यह एक घोषणा है जिसमें कार्यक्रम का "अन्य स्थान" वर्तमान एक के साथ मेल खाता है)।

चरों के लिए दो प्रकार की परिभाषाएँ हैं:

• वैश्विक चर जो कार्यक्रम के पूरे जीवन चक्र ("स्थिर आवंटन") में मौजूद हैं और जो विभिन्न कार्यों में उपलब्ध हैं;
  
• स्थानीय चर जो केवल कुछ निष्पादन योग्य फ़ंक्शन ("स्थानीय स्थान") की सीमा के भीतर मौजूद हैं और जो केवल इस फ़ंक्शन के भीतर ही पहुंच योग्य हैं।
  

इसके अलावा, "उपलब्ध" शब्द को "परिभाषा के समय चर के साथ जुड़े नाम से संदर्भित कर सकते हैं" के रूप में समझा जाना चाहिए।

कुछ विशेष मामले हैं जो पहली बार स्पष्ट प्रतीत नहीं होते हैं:

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

यह ध्यान देने योग्य है कि, किसी फ़ंक्शन को स्थैतिक के रूप में परिभाषित करने से, जिन स्थानों से आप इस फ़ंक्शन को नाम से एक्सेस कर सकते हैं, उनकी संख्या बस कम हो जाती है।

वैश्विक और स्थानीय चरों के लिए, हम एक वैरिएबल के बीच अंतर कर सकते हैं कि आरम्भिक या नहीं, अर्थात्। क्या स्मृति में चर के लिए आरक्षित स्थान एक निश्चित मूल्य से भरा होगा।

अंत में, हम जानकारी को मेमोरी में स्टोर कर सकते हैं जो कि malloc या new का उपयोग करके गतिशील रूप से आवंटित किया गया है। इस मामले में, नाम से आवंटित मेमोरी तक पहुंचना संभव नहीं है, इसलिए आपको पॉइंटर्स - नामांकित चर का उपयोग करने की आवश्यकता है जिसमें एक अनाम मेमोरी क्षेत्र का पता होता है। इस मेमोरी क्षेत्र को free या delete का उपयोग करके भी मुक्त किया जा सकता है। इस मामले में, हम "गतिशील आवंटन" के साथ काम कर रहे हैं।

संक्षेप में:

	कोड	डेटा
		वैश्विक		स्थानीय		गतिशील
		initia- liziro- बाथरूम	Neinitsia- liziro- बाथरूम	initia- liziro- बाथरूम	Neinitsia- liziro- बाथरूम
Obyav- Lenie	int fn(int x);	extern int x;	extern int x;	एन / ए	एन / ए	एन / ए
निर्धारित Lenie	int fn(int x) { ... }	int x = 1; (स्कोप - फ़ाइल)	int x; (गुंजाइश - फ़ाइल)	int x = 1; (गुंजाइश - समारोह)	int x; (गुंजाइश - समारोह)	int* p = malloc(sizeof(int));

शायद सीखने का सबसे आसान तरीका सिर्फ एक उदाहरण कार्यक्रम को देखना है।

 /*     */ int x_global_uninit; /*     */ int x_global_init = 1; /*    ,   *         C  */ static int y_global_uninit; /*    ,   *         C  */ static int y_global_init = 2; /*   ,   - *     */ extern int z_global; /*  ,   -   *  (    "extern",   * ) */ int fn_a(int x, int y); /*  .     static,   *        C . */ static int fn_b(int x) { return x+1; } /*  . */ /*     . */ int fn_c(int x_local) { /*     */ int y_local_uninit; /*     */ int y_local_init = 3; /* ,       , *      */ x_global_uninit = fn_a(x_local, x_global_init); y_local_uninit = fn_a(x_local, y_local_init); y_local_uninit += fn_b(z_global); return (x_global_uninit + y_local_uninit); } 

सी कंपाइलर क्या करता है

सी कंपाइलर का काम टेक्स्ट (आमतौर पर) मानव-पठनीय को ऐसी चीज़ में बदलना है जो कंप्यूटर समझता है। आउटपुट पर, कंपाइलर एक ऑब्जेक्ट फ़ाइल का उत्पादन करता है। UNIX प्लेटफार्मों पर, इन फ़ाइलों में आमतौर पर प्रत्यय .o होता है; विंडोज पर, प्रत्यय .obj। ऑब्जेक्ट फ़ाइल की सामग्री अनिवार्य रूप से दो चीजें हैं:

• C फ़ाइल में फ़ंक्शन परिभाषा के अनुरूप कोड
• C फ़ाइल में वैश्विक चर की परिभाषा के अनुरूप डेटा (आरंभिक वैश्विक चर के लिए, चर का प्रारंभिक मूल्य भी ऑब्जेक्ट फ़ाइल में संग्रहीत किया जाना चाहिए)।

कोड और डेटा, इस मामले में, उनके साथ जुड़े नाम होंगे - फ़ंक्शन या चर के नाम जिनके साथ वे परिभाषा से जुड़े हैं।

ऑब्जेक्ट कोड (क्रमिक रूप से रचित) मशीन निर्देशों का एक अनुक्रम है जो एक प्रोग्रामर द्वारा लिखे गए सी निर्देशों के अनुरूप है: ये सभी if 's और while ' s goto भी। इन मंत्रों को एक निश्चित प्रकार की जानकारी में हेरफेर करना चाहिए, और जानकारी कहीं न कहीं होनी चाहिए - इसके लिए हमें चर की आवश्यकता है। कोड अन्य कोड (विशेष रूप से, प्रोग्राम में अन्य C फ़ंक्शन) को भी संदर्भित कर सकता है।

जहां भी कोड एक चर या फ़ंक्शन को संदर्भित करता है, कंपाइलर केवल इसे अनुमति देता है यदि उसने पहले उस चर या फ़ंक्शन की घोषणा देखी हो। एक घोषणा एक वादा है कि परिभाषा कार्यक्रम में कहीं और मौजूद है।

लिंकर का काम इन वादों को सत्यापित करना है। हालाँकि, इन सभी वादों के साथ कंपाइलर क्या करता है जब वह ऑब्जेक्ट फ़ाइल बनाता है?

अनिवार्य रूप से, कंपाइलर खाली स्थान छोड़ देता है। एक खाली जगह (लिंक) का एक नाम है, लेकिन इस नाम के अनुरूप मूल्य अभी तक ज्ञात नहीं है।

इसे देखते हुए, हम ऊपर दिए गए प्रोग्राम के अनुसार ऑब्जेक्ट फाइल को निम्नानुसार दर्शा सकते हैं:

ऑब्जेक्ट फ़ाइल पार्स करना

अब तक, हमने उच्च स्तर पर सब कुछ माना है। हालांकि, यह देखना उपयोगी है कि यह व्यवहार में कैसे काम करता है। हमारे लिए मुख्य उपकरण nm कमांड होगा, जो UNIX प्लेटफ़ॉर्म पर ऑब्जेक्ट फ़ाइल के प्रतीकों के बारे में जानकारी प्रदान करता है। विंडोज के लिए, dumpbin कमांड /symbols विकल्प के साथ एक अनुमानित समतुल्य है। विंडोज के लिए पोर्ट किए गए GNU बिनुटिल टूल्स भी हैं जिनमें nm.exe शामिल है।

आइए देखें कि हमारे उदाहरण से प्राप्त ऑब्जेक्ट फ़ाइल के लिए nm क्या पैदा करता है :

 Symbols from c_parts.o: Name Value Class Type Size Line Section fn_a | | U | NOTYPE| | |*UND* z_global | | U | NOTYPE| | |*UND* fn_b |00000000| t | FUNC|00000009| |.text x_global_init |00000000| D | OBJECT|00000004| |.data y_global_uninit |00000000| b | OBJECT|00000004| |.bss x_global_uninit |00000004| C | OBJECT|00000004| |*COM* y_global_init |00000004| d | OBJECT|00000004| |.data fn_c |00000009| T | FUNC|00000055| |.text 

परिणाम विभिन्न प्लेटफार्मों पर थोड़ा अलग दिख सकता है (संबंधित जानकारी के लिए man की सलाह लें), लेकिन महत्वपूर्ण जानकारी प्रत्येक चरित्र और उसके आकार (यदि मौजूद है) का वर्ग है। एक वर्ग के अलग-अलग अर्थ हो सकते हैं:

• क्लास यू अस्पष्ट संदर्भों को दर्शाता है, वही "रिक्त स्थान" जो ऊपर उल्लेख किया गया है। इस वर्ग के लिए दो ऑब्जेक्ट हैं: fn_a और z_global । ( nm कुछ संस्करण इस मामले में एक खंड *UND* या UNDEF हो सकते हैं।)
• कक्षाएं टी और टी परिभाषित कोड को दर्शाती हैं; T और T के बीच का अंतर यह है कि फ़ाइल में फ़ंक्शन स्थानीय ( t ) है या नहीं ( T ), अर्थात क्या फ़ंक्शन को static घोषित किया गया था। फिर से, कुछ प्रणालियों पर, एक खंड, जैसे .text , को प्रदर्शित किया जा सकता है।
  
• कक्षा डी और डी में आरंभिक वैश्विक चर होते हैं। इसके अलावा, स्थिर चर वर्ग डी से संबंधित हैं। यदि खंड की जानकारी मौजूद है, तो यह .data होगा।
  
• असिंचित वैश्विक चर के लिए, हम b प्राप्त करते हैं यदि वे स्थिर और B या C हैं अन्यथा। इस मामले में अनुभाग सबसे अधिक संभावना .bs या * COM * होगा ।
  

आप उन वर्णों को भी देख सकते हैं जो स्रोत C कोड का हिस्सा नहीं हैं। हम इस पर अपना ध्यान केंद्रित नहीं करेंगे, क्योंकि यह आमतौर पर संकलक के आंतरिक तंत्र का हिस्सा है, ताकि आपका कार्यक्रम अभी भी संकलित किया जा सके।

लिंकर क्या करता है: भाग 1

इससे पहले, हमने उल्लेख किया कि फंक्शन या वैरिएबल घोषित करना कंपाइलर के लिए एक वादा है, कि कहीं और प्रोग्राम में उस फंक्शन या वेरिएबल की परिभाषा है, और लिंकर का काम उस वादे को पूरा करना है। ऑब्जेक्ट फ़ाइल के आरेख को देखते हुए, हम इस प्रक्रिया को "खाली स्थानों को भरने" के रूप में वर्णित कर सकते हैं।

हम एक उदाहरण के साथ इसका उदाहरण देते हैं, जो ऊपर दी गई थी के अलावा एक और सी फ़ाइल पर विचार करता है ।

 /*    */ int z_global = 11; /*      y_global_init,    static */ static int y_global_init = 2; /*     */ extern int x_global_init; int fn_a(int x, int y) { return(x+y); } int main(int argc, char *argv) { const char *message = "Hello, world"; return fn_a(11,12); } 

दोनों आरेखों के आधार पर, हम देख सकते हैं कि सभी बिंदुओं को जोड़ा जा सकता है (यदि नहीं, तो लिंकर एक त्रुटि संदेश देगा)। हर चीज की अपनी जगह होती है, और हर जगह की अपनी चीज होती है। इसके अलावा, लिंकर सभी खाली जगहों को भर सकता है जैसा कि यहां दिखाया गया है (UNIX सिस्टम पर, लिंकिंग प्रक्रिया आमतौर पर ld कमांड द्वारा लागू की जाती है)।



ऑब्जेक्ट फ़ाइलों के साथ के रूप में, हम अंतिम निष्पादन योग्य की जांच करने के लिए nm का उपयोग कर सकते हैं।

 Symbols from sample1.exe: Name Value Class Type Size Line Section _Jv_RegisterClasses | | w | NOTYPE| | |*UND* __gmon_start__ | | w | NOTYPE| | |*UND* __libc_start_main@@GLIBC_2.0 | U | FUNC|000001ad| |*UND* _init |08048254| T | FUNC| | |.init _start |080482c0| T | FUNC| | |.text __do_global_dtors_aux|080482f0| t | FUNC| | |.text frame_dummy |08048320| t | FUNC| | |.text fn_b |08048348| t | FUNC|00000009| |.text fn_c |08048351| T | FUNC|00000055| |.text fn_a |080483a8| T | FUNC|0000000b| |.text main |080483b3| T | FUNC|0000002c| |.text __libc_csu_fini |080483e0| T | FUNC|00000005| |.text __libc_csu_init |080483f0| T | FUNC|00000055| |.text __do_global_ctors_aux|08048450| t | FUNC| | |.text _fini |08048478| T | FUNC| | |.fini _fp_hw |08048494| R | OBJECT|00000004| |.rodata _IO_stdin_used |08048498| R | OBJECT|00000004| |.rodata __FRAME_END__ |080484ac| r | OBJECT| | |.eh_frame __CTOR_LIST__ |080494b0| d | OBJECT| | |.ctors __init_array_end |080494b0| d | NOTYPE| | |.ctors __init_array_start |080494b0| d | NOTYPE| | |.ctors __CTOR_END__ |080494b4| d | OBJECT| | |.ctors __DTOR_LIST__ |080494b8| d | OBJECT| | |.dtors __DTOR_END__ |080494bc| d | OBJECT| | |.dtors __JCR_END__ |080494c0| d | OBJECT| | |.jcr __JCR_LIST__ |080494c0| d | OBJECT| | |.jcr _DYNAMIC |080494c4| d | OBJECT| | |.dynamic _GLOBAL_OFFSET_TABLE_|08049598| d | OBJECT| | |.got.plt __data_start |080495ac| D | NOTYPE| | |.data data_start |080495ac| W | NOTYPE| | |.data __dso_handle |080495b0| D | OBJECT| | |.data p.5826 |080495b4| d | OBJECT| | |.data x_global_init |080495b8| D | OBJECT|00000004| |.data y_global_init |080495bc| d | OBJECT|00000004| |.data z_global |080495c0| D | OBJECT|00000004| |.data y_global_init |080495c4| d | OBJECT|00000004| |.data __bss_start |080495c8| A | NOTYPE| | |*ABS* _edata |080495c8| A | NOTYPE| | |*ABS* completed.5828 |080495c8| b | OBJECT|00000001| |.bss y_global_uninit |080495cc| b | OBJECT|00000004| |.bss x_global_uninit |080495d0| B | OBJECT|00000004| |.bss _end |080495d4| A | NOTYPE| | |*ABS* 

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

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

चरित्रों की नकल करो

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

सी ++ में, समाधान सीधा है। भाषा की एक सीमा है, जिसे एक परिभाषा के नियम के रूप में जाना जाता है, जिसमें कहा गया है कि लेआउट के दौरान सामना किए गए प्रत्येक चरित्र के लिए केवल एक परिभाषा होनी चाहिए, कोई अधिक नहीं, कम नहीं। (C ++ मानक का संगत अध्याय 3.2 है, जिसमें कुछ अपवादों का भी उल्लेख है, जिनके बारे में हम थोड़ी देर बाद चर्चा करेंगे)

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

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

परिणामस्वरूप, UNIX लिंकर्स के लिए डुप्लिकेट वर्णों की उपस्थिति की कसम खाना बिलकुल नहीं है, कम से कम यदि वे बिना लाइसेंस वाले वैश्विक चर के डुप्लिकेट वर्ण हैं (यह लेआउट मॉडल कभी-कभी "ढीली युग्मन वाला मॉडल" कहा जाता है] [यह मेरा मुफ्त अनुवाद है । def मॉडल। बेहतर सुझावों का स्वागत है])। यदि यह आपको परेशान करता है (और शायद आपको परेशान करना चाहिए), तो अपने व्यवहार को शांत करने वाले - --- विकल्प को खोजने के लिए अपने लिंकर दस्तावेज से परामर्श करें। उदाहरण के लिए, GNU -fno-common , -fno-common संकलक विकल्प आपको आम (COMMON) ब्लॉक बनाने के बजाय BBS सेगमेंट में एक -fno-common वैरिएबल रखने के लिए मजबूर करता है।

ऑपरेटिंग सिस्टम क्या करता है?

अब जब लिंकर ने एक निष्पादन योग्य फ़ाइल का उत्पादन किया है, तो प्रत्येक लिंक को प्रतीक के लिए उपयुक्त परिभाषा प्रदान करते हुए, आप यह समझने के लिए संक्षेप में विराम दे सकते हैं कि जब आप निष्पादन के लिए प्रोग्राम चलाते हैं तो ऑपरेटिंग सिस्टम क्या करता है।

पाठ्यक्रम का एक कार्यक्रम चलाना मशीन कोड के निष्पादन को पूरा करता है, अर्थात। ओएस को स्पष्ट रूप से हार्ड डिस्क से ऑपरेटिंग मेमोरी के मशीन कोड को ऑपरेटिंग मेमोरी में स्थानांतरित करने की आवश्यकता होती है, जहां से सीपीयू इसे उठा सकता है। इन भागों को एक कोड खंड (कोड खंड या पाठ खंड) कहा जाता है।

डेटा के बिना कोड अपने आप में बेकार है। इसलिए, सभी वैश्विक चर को भी कंप्यूटर की मेमोरी में जगह की आवश्यकता होती है। हालाँकि, आरंभिक और गैर-मानकीकृत वैश्विक चर के बीच अंतर है। आरंभिक चर में कुछ प्रारंभिक मूल्य होते हैं, जिन्हें ऑब्जेक्ट और निष्पादन योग्य फ़ाइलों में भी संग्रहीत किया जाना चाहिए। जब प्रोग्राम शुरू होता है, तो ओएस इन मानों को प्रोग्राम के वर्चुअल स्पेस में डेटा सेगमेंट में कॉपी करता है।

असिंचित चर के लिए, OS मान सकता है कि उनके पास प्रारंभिक मूल्य के रूप में 0 है, अर्थात। किसी भी मान को कॉपी करने की आवश्यकता नहीं है। स्मृति का एक टुकड़ा जो शून्य से आरंभ होता है उसे bss खंड के रूप में जाना जाता है।

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



जैसा कि आपने देखा होगा कि अभी तक ऑब्जेक्ट फ़ाइलों और लिंकर के बारे में सभी चर्चाओं में हम केवल वैश्विक चर के बारे में बात कर रहे हैं; हमने स्थानीय चर का उल्लेख नहीं किया है और गतिशील रूप से व्याप्त स्मृति का उल्लेख किया है ।

इस डेटा को लिंकर के हस्तक्षेप की आवश्यकता नहीं है, क्योंकि उनका जीवनकाल कार्यक्रम के निष्पादन के दौरान शुरू और समाप्त होता है - बहुत बाद में लिंकर ने अपना काम किया है। हालाँकि, वर्णन की पूर्णता के लिए, हम संक्षेप में संकेत देते हैं कि:

• स्थानीय चर एक मेमोरी क्षेत्र में स्थित होते हैं जिसे स्टैक कहा जाता है, जो बढ़ता है और विभिन्न कार्यों को बुलाया और निष्पादित किया जाता है।
  
• गतिशील रूप से आवंटित मेमोरी को हीप के रूप में ज्ञात मेमोरी क्षेत्र से लिया जाता है, और इस क्षेत्र में मॉलोक फ़ंक्शन नि: शुल्क स्थान तक पहुंच को नियंत्रित करता है।
  

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

लिंकर क्या करता है; भाग २

अब जब हमने लिंकर का क्या किया है, इसकी मूल बातों को कवर किया है, तो हम अधिक जटिल भागों के विवरण में गोता लगा सकते हैं - लगभग उसी कालानुक्रमिक क्रम में जैसे वे लिंकर में जोड़े गए थे।

मुख्य अवलोकन जो लिंकर के कार्यों को प्रभावित करता है वह निम्न है: यदि कई अलग-अलग प्रोग्राम एक ही चीज़ों के बारे में करते हैं (स्क्रीन पर आउटपुट, हार्ड डिस्क से फ़ाइलों को पढ़ना, आदि), तो जाहिर है कि यह एक निश्चित स्थान पर इस कोड को अलग करने और दूसरों को देने के लिए समझ में आता है। कार्यक्रमों का उपयोग करने के लिए।

एक ही संभव समाधान एक ही ऑब्जेक्ट फ़ाइलों का उपयोग करना होगा, लेकिन पूरे संग्रह को रखने के लिए यह अधिक सुविधाजनक होगा ... एक आसानी से सुलभ जगह में ऑब्जेक्ट फ़ाइलों का: एक पुस्तकालय ।

तकनीकी विषयांतर: यह अध्याय पूरी तरह से लिंकर की महत्वपूर्ण संपत्ति को छोड़ देता है: स्थानांतरण। विभिन्न कार्यक्रमों के अलग-अलग आकार होते हैं, अर्थात्। यदि साझा लाइब्रेरी को विभिन्न कार्यक्रमों के पते स्थान पर मैप किया जाता है, तो इसके अलग-अलग पते होंगे।बदले में इसका मतलब है कि पुस्तकालय में सभी कार्य और चर अलग-अलग स्थानों पर होंगे। अब, यदि सभी पतों तक पहुँच सापेक्ष है ("मान +1020 बाइट यहाँ से") निरपेक्ष ("मान 0x102218BF") के बजाय, तो यह कोई समस्या नहीं है, लेकिन यह हमेशा नहीं होता है। ऐसे मामलों में, सभी पूर्ण पते को एक उपयुक्त ऑफसेट के साथ जोड़ा जाना चाहिए - यह स्थानांतरण है । मैं इस विषय पर फिर से नहीं जा रहा हूं, लेकिन मैं यह जोड़ूंगा कि चूंकि यह लगभग हमेशा C / C ++ प्रोग्रामर से छिपा हुआ है, इसलिए कठिनाइयों को आगे बढ़ाने के कारण होने वाली समस्याओं को जोड़ने के लिए यह बहुत दुर्लभ है।

स्थैतिक पुस्तकालय

एक पुस्तकालय का सबसे सरल अवतार एक स्थिर पुस्तकालय है। पिछले अध्याय में, यह उल्लेख किया गया था कि आप ऑब्जेक्ट फ़ाइलों का पुन: उपयोग करके कोड साझा कर सकते हैं; यह स्थैतिक पुस्तकालयों का सार है।

यूनिक्स प्रणालियों में, आदेश एक स्थिर पुस्तकालय का निर्माण आम तौर पर है गिरफ्तारी , और पुस्तकालय फ़ाइल है, जो इस मामले में पता चला है, विस्तार * .a है। इसके अलावा, इन फ़ाइलों में आमतौर पर उनके नाम में उपसर्ग "लिबास" होता है और वे उपसर्ग और एक्सटेंशन के बिना लाइब्रेरी नाम के बाद "-l" विकल्प के साथ लिंकर को पास किए जाते हैं (यानी, "-प्रबंधित" फाइल "libredred.a") उठाएगी।
(पहले, ranlibलाइब्रेरी के शुरुआत में पात्रों की एक सूची तैयार करने के लिए स्थैतिक पुस्तकालयों के लिए एक कार्यक्रम की आवश्यकता थी। आजकल।arवे इसे स्वयं करते हैं।)

विंडोज पर, स्टैटिक लाइब्रेरीज़ का विस्तार होता है .LIBऔर उन्हें LIB टूल द्वारा एकत्रित किया जाता है, लेकिन यह तथ्य भ्रामक हो सकता है, क्योंकि उसी एक्सटेंशन का उपयोग "इंपोर्ट लाइब्रेरी" के लिए भी किया जाता है, जिसमें केवल वही सूची होती है जो DLL में होती है - विंडोज DLL पर अध्याय देखें

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

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

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

हम स्थिति को स्पष्ट करने के लिए एक उदाहरण देते हैं; मान लें कि हमारे पास निम्न ऑब्जेक्ट फ़ाइलें और एक निर्माण कमांड लाइन है जिसमें शामिल हैंao, bo, -lxऔर -ly।

फ़ाइल	ao	bo	libx.a			liby.a
वस्तु	ao	bo	x1.o	x2.o	x3.o	y1.o	y2.o	y3.o
Oprede- Lenia	a1, a2, a3	b1, b2	x11, x12, x13	x21, x22, x23	x31, x32	y11, y12	y21, y22	y31, y32
न सुलझा हुआ shonnye लिंक	b2, x12	a3, y22	x23, y12	y11		y21		x31

एक बार जब लिंकर संसाधित aoऔर boजुड़ा हुआ b2है और a3अनुमति दी जाएगी, जबकि x12और y22अभी भी अनसुलझे हैं। इस बिंदु पर, लिंकर libx.aलापता पात्रों के लिए पहले पुस्तकालय की जांच करता है और पाता है कि x1.oलिंक के लिए क्षतिपूर्ति करने के लिए इसमें क्या शामिल हो सकता है x12; हालाँकि, ऐसा करने पर, x23उन्हें y12अपरिभाषित लिंक की सूची में जोड़ दिया जाता है (अब सूची जैसा दिखता है y22, x23, y12)।

लिंकर अभी भी साथ काम कर रहा है libx.a, इसलिए लिंक को x23आसानी से मुआवजा दिया जाता है, जिसमें x2.oसे भी शामिल है libx.a। हालाँकि, यह y11अपरिभाषित की सूची में जुड़ जाता है (जो बन गया y22, y12, y11)। इनमें से किसी भी लिंक का उपयोग करने की अनुमति नहीं दी जा सकती हैlibx.aइसलिए लिंकर को लिया जाता है liby.a।

उसी के बारे में यहाँ होता है और लिंकर शामिल है y1.oऔर y2.o। पहले ऑब्जेक्ट को एक लिंक जोड़ा जाता है y21, लेकिन चूंकि यह y2.oअभी भी शामिल होगा, इस लिंक को बस हल किया जाता है। इस प्रक्रिया का परिणाम यह है कि सभी अपरिभाषित संदर्भों को हल किया जाता है, और कुछ (लेकिन सभी नहीं) पुस्तकालय वस्तुओं को अंतिम निष्पादन योग्य में शामिल किया जाता है।

ध्यान दें कि स्थिति कुछ हद तक बदलती है, अगर कहते हैं, मैं boभी एक लिंक था y32। यदि ऐसा होता, तो लेआउट libx.aभी होता, लेकिन प्रसंस्करण में liby.aसमावेश होता y3.o। इस ऑब्जेक्ट को शामिल करके हम जोड़ देंगेx31अनसुलझे पात्रों की सूची और यह लिंक अनसुलझे रहेंगे - इस स्तर पर, लिंकर ने पहले ही प्रसंस्करण पूरा कर लिया है libx.aऔर इसलिए अब इस प्रतीक (c x3.o) की परिभाषा नहीं मिलेगी ।

(वैसे, इस उदाहरण में पुस्तकालयों के बीच एक चक्रीय निर्भरता है libx.aऔर liby.aयह आमतौर पर विंडोज के तहत खराब है )

गतिशील साझा पुस्तकालय

लोकप्रिय पुस्तकालयों के लिए जैसे मानक सी लाइब्रेरी (आमतौर पर libc) एक स्थिर पुस्तकालय होने का एक स्पष्ट दोष है - प्रत्येक निष्पादन योग्य कार्यक्रम में एक ही कोड की एक प्रति होगी। वास्तव में, यदि प्रत्येक निष्पादन योग्य फ़ाइल में एक प्रतिलिपि है printf, fopenऔर जैसी है, तो अनावश्यक रूप से बहुत डिस्क स्थान पर कब्जा कर लिया जाएगा।

एक कम स्पष्ट दोष यह है कि एक सांख्यिकीय रूप से जुड़े कार्यक्रम में, कोड हमेशा के लिए तय हो जाता है। यदि कोई बग printfको ढूंढता है और उसे ठीक करता है , तो प्रत्येक प्रोग्राम को सही कोड प्राप्त करने के लिए फिर से इकट्ठा करना होगा।

इन और अन्य समस्याओं से छुटकारा पाने के लिए, गतिशील रूप से साझा किए गए पुस्तकालयों को प्रस्तुत किया गया था (आमतौर पर उनका विस्तार .soया तो .dllविंडोज में है और.dylibMac OS X पर)। इस प्रकार की लाइब्रेरी के लिए, लिंक करने वाले को सभी बिंदुओं को जोड़ना जरूरी नहीं है। इसके बजाय, लिंकर एक "IOU" प्रकार का कूपन जारी करता है (आई ओव यू = आई यू यू) और कार्यक्रम शुरू होने तक इस कूपन को कैश करने में देरी करता है।

यह सब इस तथ्य से उबलता है कि यदि लिंकर को पता चलता है कि किसी विशेष वर्ण की परिभाषा साझा लाइब्रेरी में है, तो वह इस परिभाषा को अंतिम निष्पादन योग्य फ़ाइल में शामिल नहीं करता है। इसके बजाय, लिंकर प्रतीक और पुस्तकालय का नाम लिखता है जहां से उस प्रतीक को प्रदर्शित किया जाना चाहिए।

जब प्रोग्राम को निष्पादन के लिए आमंत्रित किया जाता है, तो ओएस सुनिश्चित करता है कि कार्यक्रम शुरू होने से पहले बिल्ड प्रक्रिया के शेष हिस्सों को समय पर पूरा किया जाए। किसी फ़ंक्शन को कॉल करने से पहले main, लिंकर का एक छोटा संस्करण (जिसे अक्सर कहा जाता हैld.so) वादों की सूची के माध्यम से जाता है और अंतिम लिंकिंग एक्ट को मौके पर करता है - लाइब्रेरी कोड डालता है और सभी बिंदुओं को जोड़ता है।

इसका मतलब है कि किसी भी निष्पादन योग्य फ़ाइल में कोड की एक प्रति नहीं है printf। यदि नया संस्करण printfउपलब्ध है, तो इसे बस बदलकर उपयोग किया जा सकता है libc.so- अगली बार जब कार्यक्रम शुरू होगा, तो एक नया printfकॉल किया जाएगा ।

स्थिर पुस्तकालयों की तुलना में गतिशील पुस्तकालय कैसे काम करते हैं, इसके बीच एक और बड़ा अंतर है और यह लेआउट की ग्रैन्युलैरिटी में प्रकट होता है। यदि एक विशिष्ट वर्ण एक विशिष्ट गतिशील पुस्तकालय से लिया जाता है (कहो तो) printfसेlibc.so), फिर पुस्तकालय की सभी सामग्री कार्यक्रम के पते स्थान में रखी गई है। स्थैतिक पुस्तकालयों से यह मुख्य अंतर है, जहां केवल अपरिभाषित चरित्र से संबंधित विशिष्ट वस्तुओं को जोड़ा जाता है।

हम अलग-अलग तरह से साझा करते हैं, साझा किए गए पुस्तकालयों को स्वयं लिंकर के परिणामस्वरूप प्राप्त किया जाता है (और वस्तुओं के एक बड़े ढेर के रूप में नहीं, जैसा कि यह होता है ar), पुस्तकालय में वस्तुओं के बीच के लिंक से युक्त होता है। मैं दोहराता हूं nmकि यह क्या हो रहा है, यह स्पष्ट करने के लिए एक उपयोगी उपकरण है: ऊपर दिए गए उदाहरण के लिए, यह प्रत्येक ऑब्जेक्ट के लिए अलग से कई परिणाम देगा, यदि यह उपकरण लाइब्रेरी के स्थिर संस्करण पर चलाया जाता है, लेकिन लाइब्रेरी के साझा संस्करण के लिए यह liby.soकेवल एक अपरिभाषित चरित्र है।x31। इसके अलावा के अंत में पुस्तकालयों के शामिल किए जाने के आदेश के उदाहरण में पिछले अध्याय में भी कोई समस्या नहीं नहीं होगा: करने के लिए ऐड लिंक y32में bcकोई भी परिवर्तन आवश्यक नहीं होगा, क्योंकि सभी सामग्री y3.oऔर x3.oशामिल किया गया है।

तो वैसे, एक और उपयोगी उपकरण यह है ldd; यूनिक्स मंच पर, यह सभी साझा पुस्तकालयों को दर्शाता है कि निष्पादन योग्य बाइनरी (या एक अन्य साझा पुस्तकालय) पर निर्भर करता है, साथ ही यह संकेत भी देता है कि ये पुस्तकालय कहां मिल सकते हैं। कार्यक्रम को सफलतापूर्वक शुरू करने के लिए, लोडर को अपने सभी आश्रितों के साथ इन सभी पुस्तकालयों को खोजने की आवश्यकता है। (आमतौर पर, लोडर पर्यावरण चर में निर्दिष्ट निर्देशिकाओं की सूची में पुस्तकालयों की तलाश करता है LD_LIBRARY_PATH।)

 /usr/bin:ldd xeyes linux-gate.so.1 => (0xb7efa000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb7edb000) libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb7ec6000) libXt.so.6 => /usr/lib/libXt.so.6 (0xb7e77000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb7d93000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb7d8b000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb7d74000) libm.so.6 => /lib/libm.so.6 (0xb7d4e000) libc.so.6 => /lib/libc.so.6 (0xb7c05000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7c01000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7bff000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7be8000) libdl.so.2 => /lib/libdl.so.2 (0xb7be4000) /lib/ld-linux.so.2 (0xb7efb000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7bdf000) 

अधिक ग्रैन्युलैरिटी का कारण यह है कि आधुनिक ऑपरेटिंग सिस्टम पर्याप्त बुद्धिमान हैं जो आपको स्थैतिक पुस्तकालयों की तुलना में डिस्क पर डुप्लिकेट आइटम को सहेजने से अधिक करने की अनुमति देते हैं। एक ही साझा लाइब्रेरी का उपयोग करने वाली विभिन्न निष्पादन योग्य प्रक्रियाएं एक कोड सेगमेंट (लेकिन एक डेटा सेगमेंट या एक बीएसएस सेगमेंट नहीं) भी साझा कर सकती हैं - उदाहरण के लिए, उपयोग करते समय, दो अलग-अलग प्रक्रियाएं अलग-अलग स्थानों में हो सकती हैं strtok। इसे प्राप्त करने के लिए, पूरे पुस्तकालय को एक झटके में संबोधित किया जाना चाहिए, ताकि सभी आंतरिक लिंक एक अनूठे तरीके से निर्मित हों। वास्तव में, यदि एक प्रक्रिया aoऔर co, और दूसरी boऔर co, तो OS किसी भी मैच का उपयोग करने में सक्षम नहीं होगा।

विंडोज डीएल

इस तथ्य के बावजूद कि साझा पुस्तकालयों के सामान्य सिद्धांत यूनिक्स और विंडोज दोनों प्लेटफार्मों पर लगभग समान हैं, फिर भी कुछ विवरण हैं जो न्यूबाय पर पकड़ सकते हैं।

निर्यात किए गए प्रतीक

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

एक प्रतीक और एक Windows DLL निर्यात करने के तीन तरीके हैं (और इन तीनों तरीकों को एक ही पुस्तकालय में मिलाया जा सकता है)।

• स्रोत कोड में, वर्ण को__declspec(dllexport) कुछ इस तरह घोषित करें:
  

   __declspec(dllexport) int my_exported_function(int x, double y) 

  
  
• लिंकर कमांड को निष्पादित करते समय, विकल्प का उपयोग करेंLINK.EXE export: symbol_to_export
  

   LINK.EXE /dll /export:my_exported_function 

  
  
• मॉड्यूल परिभाषा फ़ाइल (DEF) को लिंकर (विकल्प का उपयोग करके /DEF: def_file) इस फ़ाइल में एक अनुभाग शामिल करके फ़ीड करें EXPORTजिसमें निर्यात किए जाने वाले वर्ण हैं।
  

   EXPORTS my_exported_function my_other_exported_function 

  
  

जैसे ही C ++ इस मिशमाश से जुड़ा होता है, इनमें से पहला विकल्प सबसे सरल हो जाता है, क्योंकि इस मामले में संकलक नामों को सजाने का ध्यान रखता है

.LIB और अन्य पुस्तकालय से संबंधित फाइलें

हम विंडोज पुस्तकालयों से जुड़ी दूसरी कठिनाई पर आते हैं: निर्यात किए गए प्रतीकों के बारे में जानकारी, जिसे लिंकर को बाकी प्रतीकों के साथ जोड़ना होगा, अपने आप में सम्‍मिलित नहीं है DLL। इसके बजाय, यह जानकारी संबंधित .LIBफ़ाइल में निहित है ।

.LIBफ़ाइल से संबंधित DLLवर्णन करता है कि कौन से (निर्यात) वर्ण DLLअपने स्थान के साथ हैं। कोई भी बाइनरी जो वर्णों को सही ढंग से जोड़ने के DLLलिए .LIBफ़ाइल का उपयोग करना चाहिए ।

चीजों को और अधिक भ्रमित करने के लिए, विस्तार का .LIBउपयोग स्थिर पुस्तकालयों के लिए भी किया जाता है।

वास्तव में, कई अलग-अलग फाइलें हैं जो किसी तरह से विंडोज लाइब्रेरी से संबंधित हो सकती हैं। साथ में.LIBफ़ाइल, साथ ही एक वैकल्पिक (वैकल्पिक) .DEFफ़ाइल, आप अपनी Windows लाइब्रेरी से जुड़ी सभी निम्न फ़ाइलों को देख सकते हैं।

• लेआउट आउटपुट फ़ाइलें
  
  • पुस्तकालय .DLL : वास्तविक पुस्तकालय कोड; लाइब्रेरी का उपयोग करके किसी भी बाइनरी द्वारा इस फ़ाइल की आवश्यकता है (रनटाइम पर)।
    
  • लाइब्रेरी .LIB : एक "लाइब्रेरी इंपोर्ट" फ़ाइल जो बताती है कि परिणामी एक में कहाँ और क्या प्रतीक है DLL। यह फ़ाइल उत्पन्न होती है यदि यह केवल DLLअपने कुछ पात्रों को निर्यात करती है। यदि वर्ण निर्यात नहीं किए जाते हैं, तो .LIBफ़ाइल का कोई मतलब नहीं है । लिंकिंग के दौरान इस फाइल की जरूरत होती है।
    
  • पुस्तकालय .EXP : संकलित पुस्तकालय की "निर्यात फ़ाइल", जो कि जरूरत पड़ने पर चक्रीय निर्भरता वाले बायनेरिज़ मौजूद हैं ।
    
  • library .ILK : /INCREMENTAL , , . .
    
  • library .PDB : /DEBUG , , .
    
  • library .MAP : /MAP , .
    
  
  
• :
  
  • library .LIB : « », DLL , .
    
  • library .LIB : , , . .LIB
    
  • library .DEF : «», , .
    
  • library .EXP : , , LIB.EXE .LIB . .
    
  • library .ILK : ; . .
    
  • पुस्तकालय .RES : एक संसाधन फ़ाइल जिसमें निष्पादन योग्य द्वारा उपयोग किए जाने वाले विभिन्न GUI विगेट्स के बारे में जानकारी होती है। ये संसाधन अंतिम बाइनरी में शामिल हैं।
    
  
  

यह यूनिक्स के लिए एक बड़ा अंतर है, जहां इन सभी अतिरिक्त फ़ाइलों में निहित लगभग सभी जानकारी बस लाइब्रेरी में ही जोड़ दी जाती है।

आयातित पात्र

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

ऐसा करने के लिए, वर्ण को __declspec (dllimport) के रूप में इस तरह से सोर्स कोड में घोषित करें:

 __declspec(dllimport) int function_from_some_dll(int x, double y); __declspec(dllimport) extern int global_var_from_some_dll; 

इस मामले में, एक हेडर फ़ाइल में फ़ंक्शंस या वैश्विक चर की व्यक्तिगत घोषणा सी में एक अच्छा प्रोग्रामिंग टोन है। यह कुछ प्रकार के रिबूट की ओर जाता है: फ़ंक्शन / चर की परिभाषा वाले DLL में कोड को चरित्र को निर्यात करना चाहिए , लेकिन DLL का उपयोग करने वाले किसी भी अन्य वर्ण को आयात करना होगा ।

इस स्थिति से बाहर मानक तरीका प्रीप्रोसेसर मैक्रोज़ का उपयोग करना है।

 #ifdef EXPORTING_XYZ_DLL_SYMS #define XYZ_LINKAGE __declspec(dllexport) #else #define XYZ_LINKAGE __declspec(dllimport) #endif XYZ_LINKAGE int xyz_exported_function(int x); XYZ_LINKAGE extern int xyz_exported_variable; 

DLL में स्रोत फ़ाइल जो फ़ंक्शन को परिभाषित करती है और चर यह सुनिश्चित करती है कि संबंधित हेडर फ़ाइल को शामिल करने से पहले प्रीप्रोसेसर चर को EXPORTING_XYZ_DLL_SYMSपरिभाषित किया गया है (मतलब के अनुसार #define) और इस प्रकार चरित्र निर्यात करता है। कोई भी अन्य कोड जिसमें यह हेडर फ़ाइल शामिल है, इस वर्ण को परिभाषित नहीं करता है और इस प्रकार इसे आयात करता है।

चक्रीय निर्भरता

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

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

हालांकि, यदि बायनेरिज़ के बीच एक चक्रीय निर्भरता है। तब सब कुछ थोड़ा जटिल हो जाता है। यदि आपको X.DLLकिसी प्रतीक की आवश्यकता है Y.DLL, लेकिन आपको Y.DLLप्रतीक की आवश्यकता है X.DLL, तो आपको चिकन और अंडे की समस्या को हल करने की आवश्यकता है: कोई भी चीज जो पहले पुस्तकालय से जुड़ी हुई है, वह सभी प्रतीकों की अनुमति नहीं पा सकेगी।

विंडोज ने निम्नलिखित की तरह कुछ के लिए एक वर्कअराउंड प्रदान किया ।

• X. LIB.EXE ( LINK.EXE ), X.LIB , LINK.EXE . X.DLL , X.EXP .
  
• Y , X.LIB , , Y.DLL Y.LIB .
  
• अंत में, हम Xअब पूरी तरह से पुस्तकालय की रचना करते हैं। यह X.EXPपहले चरण में प्राप्त एक अतिरिक्त फ़ाइल का उपयोग करके लगभग हमेशा की तरह होता है । इस चरण में सामान्य बात यह है कि लिंकर का उपयोग Y.LIBऔर उत्पादन क्या है X.DLL। असामान्य - लिंक करने वाला निर्माण चरण को छोड़ देता है X.LIB, क्योंकि यह फ़ाइल पहले चरण में पहले से ही बनाई गई थी, जैसा कि .EXPफ़ाइल की उपस्थिति से स्पष्ट है ।
  

लेकिन निश्चित रूप से इस तरह से पुस्तकालयों को पुनर्गठित करना बेहतर है ताकि किसी भी चक्रीय निर्भरता से बचा जा सके ...

चित्र को पूरक करने के लिए C ++

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

समारोह अतिभारित और नाम सजावट

C ++ के साथ पहला अंतर यह है कि फ़ंक्शंस को अधिभारित किया जा सकता है, अर्थात्, एक ही नाम के साथ फ़ंक्शंस, लेकिन विभिन्न स्वीकृत प्रकारों (विभिन्न फ़ंक्शन हस्ताक्षर ) के साथ एक साथ मौजूद हो सकते हैं :

 int max(int x, int y) { if (x>y) return x; else return y; } float max(float x, float y) { if (x>y) return x; else return y; } double max(double x, double y) { if (x>y) return x; else return y; } 

यह राज्य निश्चित रूप से लिंकर के काम को जटिल करता है: यदि कोई कोड किसी फ़ंक्शन को संदर्भित करता है max, तो वास्तव में क्या मतलब था?

इस समस्या का समाधान कहा जाता है नाम सजाने (नाम mangling), क्योंकि समारोह हस्ताक्षर के बारे में सभी जानकारी स्थानांतरित कर रहा है (करने के लिए वध करना = बिगाड़ना, ख़राब, prim.per। ) पाठ रूप है, जो वास्तव में लेआउट की दृष्टि से एक चरित्र का नाम है में। विभिन्न हस्ताक्षर अलग-अलग नामों में अनुवादित होते हैं। इस प्रकार, नामों की विशिष्टता की समस्या हल हो गई है।

मैं उपयोग की जाने वाली सजावट योजनाओं के विवरण में नहीं जा रहा हूं (जो कि प्लेटफॉर्म से प्लेटफॉर्म में भी भिन्न है), लेकिन ऊपर दिए गए कोड के अनुरूप ऑब्जेक्ट फ़ाइल पर एक त्वरित नज़र यह सब समझने का एक विचार देगा (याद रखें)nm - आपका दोस्त!):

 Symbols from fn_overload.o: Name Value Class Type Size Line Section __gxx_personality_v0| | U | NOTYPE| | |*UND* _Z3maxii |00000000| T | FUNC|00000021| |.text _Z3maxff |00000022| T | FUNC|00000029| |.text _Z3maxdd |0000004c| T | FUNC|00000041| |.text 

यहां हम तीन फ़ंक्शन देखते हैं max, जिनमें से प्रत्येक को ऑब्जेक्ट फ़ाइल में एक अलग नाम मिला है, और हम स्मार्ट हो सकते हैं और मान सकते हैं कि "अधिकतम" के बाद के अगले दो अक्षर इनपुट मापदंडों के प्रकारों को इंगित करते हैं - "i" जैसे int, "f" जैसे float"d" कैसे double(हालांकि, चीजें बहुत अधिक जटिल हो जाती हैं यदि कक्षाएं, नाम स्थान, टेम्पलेट और अतिभारित ऑपरेटर खेल में आते हैं!)।

यह भी ध्यान देने योग्य है कि आमतौर पर प्रोग्रामर को दिखाई देने वाले नामों और लिंकर को दिखाई देने वाले नामों के बीच कनवर्ट करने का एक तरीका है। यह एक अलग कार्यक्रम (उदाहरण के लिए c++filt) या कमांड लाइन पर एक विकल्प हो सकता है ( --demangleजीएनयू एनएम के लिए, उदाहरण के लिए ) जो कुछ इस तरह का उत्पादन करता है:

 Symbols from fn_overload.o: Name Value Class Type Size Line Section __gxx_personality_v0| | U | NOTYPE| | |*UND* max(int, int) |00000000| T | FUNC|00000021| |.text max(float, float) |00000022| T | FUNC|00000029| |.text max(double, double) |0000004c| T | FUNC|00000041| |.text 

वह क्षेत्र जहां सजावट योजनाएं अक्सर गलतियां करती हैं, वह जगह है जहां सी और सी ++ को इंटरवेट किया जाता है। C ++ कंपाइलर द्वारा निर्मित सभी पात्रों को सजाया गया है; C संकलक द्वारा निर्मित सभी वर्ण स्रोत कोड के समान दिखते हैं। इसके चारों ओर जाने के लिए, C ++ आपको extern "C"घोषणाओं को रखने और इसके चारों ओर परिभाषाएँ बनाने की अनुमति देता है। अनिवार्य रूप से, हम C ++ कंपाइलर को बताते हैं कि किसी निश्चित नाम को सजाया नहीं जाना चाहिए - या तो क्योंकि यह C ++ फ़ंक्शन की एक परिभाषा है जिसे C कोड द्वारा बुलाया जाएगा, या क्योंकि तब यह C फ़ंक्शन की एक परिभाषा है जिसे C ++ कोड कहा जाएगा।

लेख के बहुत शुरुआत में उदाहरण पर लौटते हुए, कोई आसानी से नोटिस कर सकता है कि एक उच्च संभावना है कि कोई व्यक्ति extern "C"C और C ++ को लिंक करते समय वस्तुओं का उपयोग करना भूल गया ।

 g++ -o test1 test1a.o test1b.o test1a.o(.text+0x18): In function `main': : undefined reference to `findmax(int, int)' collect2: ld returned 1 exit status 

एक बड़ा संकेत यह है कि त्रुटि संदेश में फ़ंक्शन के हस्ताक्षर शामिल हैं - यह सिर्फ एक संदेश नहीं है कि यह findmaxनहीं मिला। दूसरे शब्दों में, C ++ कोड कुछ के लिए लगता है "_Z7findmaxii", लेकिन केवल पाता है "findmax"। इसलिए, एक लेआउट त्रुटि होती है।

वैसे, ध्यान दें कि घोषणा को extern "C"कक्षाओं के सदस्य कार्यों के लिए अनदेखा किया गया है (C ++ मानक के .47.5.4)

स्थैतिक वस्तुओं की शुरुआत

लिंकर के संचालन को प्रभावित करने वाली अगली सी ++ संपत्ति ऑब्जेक्ट कंस्ट्रक्टर्स का अस्तित्व है । एक कंस्ट्रक्टर कोड का एक टुकड़ा है जो किसी ऑब्जेक्ट की प्रारंभिक स्थिति सेट करता है। संक्षेप में, उनका काम वैचारिक रूप से एक चर के मूल्य को शुरू करने के बराबर है, लेकिन महत्वपूर्ण अंतर के साथ हम कोड के मनमाने टुकड़ों के बारे में बात कर रहे हैं। पहले अध्याय

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

सी ++ में, प्रारंभिक मूल्यों को कॉपी करने की तुलना में प्रारंभिक प्रक्रिया बहुत अधिक जटिल हो सकती है; कक्षा पदानुक्रम के दौरान विभिन्न कन्स्ट्रक्टरों में सभी कोड को वास्तव में कार्यक्रम शुरू होने से पहले निष्पादित किया जाना चाहिए।

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

ध्यान दें कि आदेश, जिसमें वैश्विक वस्तुओं के डिजाइनरों को परिभाषित नहीं किया गया है - यह पूरी तरह से इसकी चपेट में है कि लिंकर क्या करना चाहता है। (आगे के विवरण के लिए स्कॉट मायर्स के प्रभावी सी ++ देखें - दूसरे संस्करण में नोट 47 , तीसरे संस्करण में नोट 4 )

हम इन सूचियों का पालन कर सकते हैं, फिर से मदद का सहारा ले सकते हैं nm। निम्नलिखित C ++ फ़ाइल पर विचार करें:

 class Fred { private: int x; int y; public: Fred() : x(1), y(2) {} Fred(int z): x(z), y(3) {} }; Fred theFred; Fred theOtherFred(55); 

इस कोड के लिए ( सजाया नहीं गया), आउटपुट nmइस तरह दिखता है:

 Symbols from global_obj.o: Name Value Class Type Size Line Section __gxx_personality_v0| | U | NOTYPE| | |*UND* __static_initialization_and_destruction_0(int, int) |00000000| t | FUNC|00000039| |.text Fred::Fred(int) |00000000| W | FUNC|00000017| |.text._ZN4FredC1Ei Fred::Fred() |00000000| W | FUNC|00000018| |.text._ZN4FredC1Ev theFred |00000000| B | OBJECT|00000008| |.bss theOtherFred |00000008| B | OBJECT|00000008| |.bss global constructors keyed to theFred |0000003a| t | FUNC|0000001a| |.text 

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

टेम्पलेट्स

इससे पहले हमने एक फ़ंक्शन के तीन अलग-अलग कार्यान्वयनों के साथ एक उदाहरण दिया max, जिनमें से प्रत्येक ने विभिन्न प्रकार के तर्क लिए। हालाँकि, हम देखते हैं कि फ़ंक्शन बॉडी कोड तीनों मामलों में समान है। और हम जानते हैं कि समान कोड को डुप्लिकेट करना एक खराब प्रोग्रामिंग टोन है।

C ++ एक टेम्पलेट की अवधारणाओं का परिचय देता है, जो आपको एक बार में सभी मामलों के लिए नीचे दिए गए कोड का उपयोग करने की अनुमति देता है। हम max_template.hफ़ंक्शन कोड की केवल एक प्रति के साथ एक हेडर फ़ाइल बना सकते हैं max:

 template <class T> T max(T x, T y) { if (x>y) return x; else return y; } 

और टेम्पलेट फ़ंक्शन को आज़माने के लिए इस फ़ाइल को स्रोत फ़ाइल में शामिल करें:

 #include "max_template.h" int main() { int a=1; int b=2; int c; c = max(a,b); //   ,    max<int>(int,int) double x = 1.1; float y = 2.2; double z; z = max<double>(x,y); //    ,   max<double>(double,double) return 0; } 

यह C ++ कोड उपयोग करता है max<int>(int,int)और max<double>(double,double)। हालाँकि, कुछ अन्य कोड इस टेम्पलेट के अन्य उदाहरणों का उपयोग कर सकते हैं। अच्छा, कहो, max<float>(float,float)या भी max<MyFloatingPointClass>(MyFloatingPointClass,MyFloatingPointClass)।

इनमें से प्रत्येक अलग प्राधिकरण एक अलग मशीन कोड बनाता है। इस प्रकार, जिस समय कार्यक्रम को अंत में इकट्ठा किया जाता है, कंपाइलर और लिंकर को यह सुनिश्चित करना होता है कि टेम्पलेट के प्रत्येक उपयोग किए गए उदाहरण के लिए कोड को प्रोग्राम में शामिल किया गया है (और टेम्पलेट के एक भी अप्रयुक्त उदाहरण को शामिल नहीं किया गया है ताकि प्रोग्राम का आकार बढ़ाना न हो)।

यह कैसे किया जाता है? आमतौर पर कार्रवाई के दो रास्ते होते हैं: या तो दोहराए जाने वाले अधिकारियों को पतला करना या निर्माण चरण को उदाहरण देना (मैं आमतौर पर इन तरीकों को सन के स्मार्ट पथ और पथ के रूप में संदर्भित करता हूं)।

उदाहरणों को दोहराने की पतली विधि का अर्थ है कि प्रत्येक ऑब्जेक्ट फ़ाइल में अंकित सभी पैटर्न का कोड होता है। उदाहरण के लिए, उपरोक्त फ़ाइल के लिए, ऑब्जेक्ट फ़ाइल की सामग्री इस तरह दिखती है:

 Symbols from max_template.o: Name Value Class Type Size Line Section __gxx_personality_v0 | | U | NOTYPE| | |*UND* double max<double>(double, double) |00000000| W | FUNC|00000041| |.text _Z3maxIdET_S0_S0_ int max<int>(int, int) |00000000| W | FUNC|00000021| |.text._Z3maxIiET_S0_S0_ main |00000000| T | FUNC|00000073| |.text 

और हम दोनों अधिकारियों की उपस्थिति देखते हैं max<int>(int,int)और max<double>(double,double)।

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

एक और दृष्टिकोण (जिसका उपयोग सोलारिस सी ++ में किया गया है) सामान्य रूप से ऑब्जेक्ट फ़ाइलों में टेम्पलेट परिभाषाओं को शामिल नहीं करना है, लेकिन उन्हें अपरिभाषित पात्रों के रूप में चिह्नित करना है। जब यह लेआउट चरण की बात आती है, तो लिंकर सभी अपरिभाषित पात्रों को एकत्र कर सकता है जो वास्तव में टेम्पलेट इंस्टेंस से संबंधित हैं, और फिर उनमें से प्रत्येक के लिए मशीन कोड उत्पन्न करते हैं।

यह निश्चित रूप से प्रत्येक ऑब्जेक्ट फ़ाइल के आकार को कम करता है, हालांकि, इस दृष्टिकोण का माइनस यह है कि लिंकर को स्रोत कोड स्थित होने का ट्रैक रखना चाहिए और लिंक करने के दौरान C ++ कंपाइलर को चलाने में सक्षम होना चाहिए (जो पूरी प्रक्रिया को धीमा कर सकता है)

गतिशील रूप से भरी हुई लाइब्रेरी

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

यह सिस्टम कॉल के एक जोड़े द्वारा किया जाता है dlopenऔर dlsym(विंडोज में लगभग समतुल्य क्रमशः कहा जाता है LoadLibraryऔर GetProcAddress)। पहले साझा लाइब्रेरी का नाम लेता है और इसे चलने की प्रक्रिया के पते स्थान में लोड करता है। बेशक, इस पुस्तकालय में अनसुलझे चरित्र भी हो सकते हैं, इसलिए एक कॉल dlopenअन्य साझा पुस्तकालयों को लोड करने में प्रवेश कर सकती है।

dlopenलायब्रेरी लोड होने के बाद या तो सभी अनसुलझे मुद्दों को समाप्त करने का विकल्प प्रदान करता है, ( RTLD_NOW) या आवश्यक के रूप में वर्णों को अनुमति देता है ( RTLD_LAZY)। पहली विधि का मतलब है कि कॉल में dlopenपर्याप्त समय लग सकता है, लेकिन दूसरी विधि में एक निश्चित जोखिम है कि कार्यक्रम के निष्पादन के दौरान एक अपरिभाषित लिंक का पता लगाया जाएगा जिसे हल नहीं किया जा सकता है - उस समय कार्यक्रम पूरा हो जाएगा।

बेशक, एक गतिशील रूप से भरी हुई लाइब्रेरी के पात्रों में एक नाम नहीं हो सकता है। हालाँकि, यह केवल एक अतिरिक्त स्तर के वर्कआर्ड को जोड़कर हल किया जाता है, साथ ही साथ अन्य प्रोग्रामिंग कार्यों को भी। इस स्थिति में, वर्ण स्थान के लिए एक सूचक का उपयोग किया जाता है। कॉलdlsymएक शाब्दिक पैरामीटर लेता है जो वर्ण के नाम की रिपोर्ट करता है, और उसके स्थान पर एक सूचक लौटाता है (या NULLयदि चरित्र नहीं मिला है)।

C ++ के साथ सहभागिता

गतिशील लोडिंग प्रक्रिया काफी सरल है, लेकिन यह विभिन्न सी ++ सुविधाओं के साथ कैसे बातचीत करता है जो सभी लिंकर व्यवहार को प्रभावित करते हैं?

पहला अवलोकन सजाने वाले नामों के बारे में है। जब बुलाया जाता है dlsym, तो पाया जाने वाला चरित्र का नाम पारित किया जाता है। तो यह लिंकर को दिखाई देने वाले नाम का संस्करण होना चाहिए, अर्थात। सजाया हुआ नाम।

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

उपरोक्त संक्षेप में, हम निम्नलिखित पर ध्यान देते हैं: आमतौर पर extern "C"प्रवेश बिंदु पर एक कैदी रखना बेहतर होता है , जो कि इस dlsymओम द्वारा पाया जा सकता है । यह एंट्री पॉइंट एक फैक्ट्री विधि हो सकती है जो C ++ क्लास के सभी इंस्टेंस पर पॉइंटर्स लौटाती है, जिससे C ++ के सभी चार्ट तक पहुँच प्राप्त की जा सकती है।

संकलक पुस्तकालय में वैश्विक वस्तुओं के डिजाइनरों के साथ काफी हद तक निपट सकता है dlopen, क्योंकि कुछ विशेष वर्ण हैं जिन्हें पुस्तकालय में जोड़ा जा सकता है और जिसे लिंकर द्वारा कहा जाएगा (यह लोडिंग या निष्पादन के दौरान कोई फर्क नहीं पड़ता) यदि पुस्तकालय गतिशील रूप से लोड या अनलोड किया गया है - तो वह यह है कि कंस्ट्रक्टरों या विध्वंसकों के लिए आवश्यक कॉल यहां हो सकती हैं। यूनिक्स पर, ये फ़ंक्शन _initऔर हैं_finiया जीएनयू उपकरण का उपयोग कर अधिक हाल ही में सिस्टम के लिए वहाँ काम करता है, के रूप में चिह्नित कर रहे हैं __attribute__((constructor))या __attribute__((destructor))। विंडोज में, संबंधित फ़ंक्शन DllMainएक पैरामीटर के DWORD fdwReasonबराबर DLL_PROCESS_ATTACHया उसके साथ है DLL_PROCESS_DETACH।

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

इसके साथ ही

इस लेख ने जानबूझकर लिंकर कैसे काम करता है, इसके बारे में कई विवरणों को नजरअंदाज कर दिया, क्योंकि मेरा मानना ​​है कि लिखित की सामग्री रोजमर्रा की समस्याओं का 95% कवर करती है जो एक प्रोग्रामर को अपने कार्यक्रम को संकलित करते समय सामना करना पड़ता है।

यदि आप अधिक जानना चाहते हैं, तो आप नीचे दिए गए लिंक से जानकारी प्राप्त कर सकते हैं:

• जॉन लेविन, लिंकर्स और लोडर : इस लेख में गायब होने वाली सभी चीजों सहित लिंकर और लोडर की पेचीदगियों के बारे में जानकारी का खजाना है । यहाँ इस पुस्तक (या इसके मसौदे) का एक ऑनलाइन संस्करण भी है ।
  
• मैक ओएस एक्स पर बायनेरिज़ के लिए माच-ओ प्रारूप के वर्णन के लिए एक महान लिंक।
  
• Peter Van Der Linden, Expert C Programming : , , , C, , C, .
  
• Scott Meyers, More Effective C++ : 34 , C C++ ( )
  
• Bjarne Stroustrup, The Design and Evolution of C++ : 11.3 C++ .
  
• Margaret A. Ellis & Bjarne Stroustrup, The Annotated C++ Reference Manual : 7.2c
  
• ELF format reference [PDF]
  
• विशेष रूप से लिनक्स पर हल्की निष्पादन योग्य फाइलें और विशेष रूप से न्यूनतम हैलो वर्ल्ड बनाने पर दो दिलचस्प लेख ।
  
• "कैसे साझा पुस्तकालयों को लिखने के लिए" [पीडीएफ] कुख्यात उलरिच ड्रेपर में ईएलएफ और अग्रेषण के बारे में अधिक विवरण हैं।
  

इस पेज के बारे में उपयोगी सुझाव के लिए माइक कैप और एड विल्सन को बहुत धन्यवाद।

---

कॉपीराइट © 2004-2005,2009-2010 डेविड ड्रायसेडेल की

अनुमति जीएनयू फ्री डॉक्यूमेंटेशन लाइसेंस, संस्करण 1.1 या फ्री सॉफ्टवेयर फाउंडेशन द्वारा प्रकाशित किसी भी बाद के संस्करण की शर्तों के तहत इस दस्तावेज़ को कॉपी, वितरित और / या संशोधित करने के लिए दी गई है; बिना मोहरे-कवर ग्रंथों के साथ, और कोई बैक-कवर ग्रंथों के साथ कोई अपरिवर्तनीय अनुभाग नहीं। लाइसेंस की एक प्रति यहां उपलब्ध है ।