संकलन और लिंकिंग प्रक्रिया कैसे काम करती है?
(नोट: यह स्टैक ओवरफ्लो के C ++ FAQ के लिए प्रविष्टि माना जाता है । यदि आप इस फॉर्म में FAQ प्रदान करने के विचार की आलोचना करना चाहते हैं, तो मेटा पर पोस्टिंग जो यह सब शुरू करती है वह करने के लिए जगह होगी। उत्तर) उस प्रश्न की निगरानी C ++ चैटरूम में की जाती है , जहाँ पहली बार में FAQ विचार शुरू हुआ है, इसलिए आपका उत्तर उन लोगों द्वारा पढ़ा जाने की संभावना है, जो विचार के साथ आए थे।)
जवाबों:
C ++ प्रोग्राम के संकलन में तीन चरण शामिल हैं:
प्रीप्रोसेसिंग: प्रीप्रोसेसर एक सी ++ स्रोत कोड फ़ाइल लेता है और #includeएस, #defineएस और अन्य प्रीप्रोसेसर निर्देशों से संबंधित होता है। इस चरण का आउटपुट प्री-प्रोसेसर निर्देशों के बिना "शुद्ध" C ++ फ़ाइल है।
संकलन: कंपाइलर प्री-प्रोसेसर के आउटपुट को लेता है और उससे एक ऑब्जेक्ट फाइल तैयार करता है।
लिंकिंग: लिंकर कंपाइलर द्वारा निर्मित ऑब्जेक्ट फाइल्स को लेता है और एक लाइब्रेरी या एक एक्जीक्यूटेबल फाइल बनाता है।
प्रीप्रोसेसर पूर्वप्रक्रमक निर्देशों को पसंद करता है, जैसे #includeऔर #define। यह C ++ के सिंटैक्स का अज्ञेय है, यही कारण है कि इसका उपयोग सावधानी से किया जाना चाहिए।
यह एक समय में एक सी ++ स्रोत फ़ाइल पर #includeसंबंधित फाइलों की सामग्री के साथ निर्देशन की जगह (जो आमतौर पर सिर्फ घोषणाएं होती है) पर काम करता है, मैक्रोज़ के प्रतिस्थापन ( #define), और पाठ के विभिन्न भागों का चयन करता है #if, #ifdefऔर #ifndefनिर्देशों के आधार पर ।
प्रीप्रोसेसर टोकन के प्रीप्रोसेसिंग की एक धारा पर काम करता है। मैक्रो प्रतिस्थापन को अन्य टोकन के साथ टोकन की जगह के रूप में परिभाषित किया गया है (ऑपरेटर ##समझ में आने पर दो टोकन को विलय करने में सक्षम बनाता है)।
इस सब के बाद, प्रीप्रोसेसर एक एकल आउटपुट का उत्पादन करता है जो ऊपर वर्णित परिवर्तनों के परिणामस्वरूप टोकन की एक धारा है। यह कुछ विशेष मार्करों को भी जोड़ता है जो संकलक को बताते हैं कि प्रत्येक पंक्ति कहाँ से आई है ताकि यह उन लोगों का उपयोग कर सकता है जो समझदार त्रुटि संदेश उत्पन्न करते हैं।
इस चरण में कुछ त्रुटियों का उत्पादन किया जा सकता है, जिनके उपयोग #ifऔर #errorनिर्देशों का चतुराई से उपयोग किया जा सकता है ।
संकलन कदम प्रीप्रोसेसर के प्रत्येक आउटपुट पर किया जाता है। संकलक शुद्ध C ++ स्रोत कोड (अब बिना किसी पूर्वप्रक्रमक निर्देश) को पार्स करता है और इसे विधानसभा कोड में परिवर्तित करता है। फिर अंतर्निहित बैक-एंड (टूलचैन में कोडांतरक) को इनवॉइस करता है जो उस कोड को मशीन कोड में कोडित करता है जो वास्तविक बाइनरी फ़ाइल को कुछ प्रारूप (ELF, COFF, a.out, ...) में कोड करता है। इस ऑब्जेक्ट फ़ाइल में इनपुट में परिभाषित प्रतीकों का संकलित कोड (बाइनरी फॉर्म में) है। ऑब्जेक्ट फ़ाइलों में प्रतीकों को नाम से संदर्भित किया जाता है।
ऑब्जेक्ट फ़ाइलें उन प्रतीकों का उल्लेख कर सकती हैं जो परिभाषित नहीं हैं। यह वह स्थिति है जब आप किसी घोषणा का उपयोग करते हैं, और इसके लिए कोई परिभाषा नहीं देते हैं। कंपाइलर को इससे कोई आपत्ति नहीं है, और जब तक स्रोत कोड अच्छी तरह से नहीं बन जाता है तब तक वह खुशी से ऑब्जेक्ट फाइल का उत्पादन करेगा।
कंपाइलर आमतौर पर आपको इस बिंदु पर संकलन बंद करने देते हैं। यह बहुत उपयोगी है क्योंकि इसके साथ आप प्रत्येक स्रोत कोड फ़ाइल को अलग से संकलित कर सकते हैं। इससे जो लाभ मिलता है, वह यह है कि अगर आपको केवल एक ही फाइल बदलनी है तो आपको हर चीज को फिर से खोलने की जरूरत नहीं है ।
उत्पादित वस्तु फ़ाइलों को बाद में आसानी से पुन: उपयोग करने के लिए, स्थिर पुस्तकालयों नामक विशेष अभिलेखागार में रखा जा सकता है।
यह इस स्तर पर है कि "नियमित" संकलक त्रुटियां, जैसे सिंटैक्स त्रुटियां या विफल अधिभार संकल्प त्रुटियां, रिपोर्ट की जाती हैं।
लिंकर वह है जो ऑब्जेक्ट से अंतिम संकलन आउटपुट का उत्पादन करता है जो संकलित फाइल का उत्पादन करता है। यह आउटपुट या तो साझा (या डायनामिक) लाइब्रेरी हो सकता है (और नाम समान होने पर, वे पहले बताई गई स्टैटिक लाइब्रेरीज़ के साथ बहुत आम नहीं हैं) या एक निष्पादन योग्य है।
यह सही पते के साथ अपरिभाषित प्रतीकों के संदर्भों को प्रतिस्थापित करके सभी ऑब्जेक्ट फ़ाइलों को जोड़ता है। इन प्रतीकों में से प्रत्येक को अन्य ऑब्जेक्ट फ़ाइलों या पुस्तकालयों में परिभाषित किया जा सकता है। यदि उन्हें मानक पुस्तकालय के अलावा अन्य पुस्तकालयों में परिभाषित किया गया है, तो आपको उनके बारे में लिंकर को बताना होगा।
इस स्तर पर सबसे आम त्रुटियां परिभाषाएं या डुप्लिकेट परिभाषाएं गायब हैं। पूर्व का मतलब है कि या तो परिभाषाएं मौजूद नहीं हैं (अर्थात वे लिखित नहीं हैं), या कि ऑब्जेक्ट फ़ाइल या लाइब्रेरी जहां वे रहते हैं, उन्हें लिंकर को नहीं दिया गया था। उत्तरार्द्ध स्पष्ट है: एक ही प्रतीक को दो अलग-अलग ऑब्जेक्ट फ़ाइलों या पुस्तकालयों में परिभाषित किया गया था।
इस विषय पर CProgramming.com: https://www.cprogramming.com/compilingandlinking.html पर चर्चा की गई है
यहाँ लेखक ने क्या लिखा है:
संकलन एक निष्पादन योग्य फ़ाइल बनाने के समान नहीं है! इसके बजाय, एक निष्पादन योग्य बनाना एक मल्टीस्टेज प्रक्रिया है जिसे दो घटकों में विभाजित किया गया है: संकलन और लिंकिंग। वास्तव में, भले ही कोई प्रोग्राम "ठीक संकलन करता है" यह लिंकिंग चरण के दौरान त्रुटियों के कारण वास्तव में काम नहीं कर सकता है। स्रोत कोड फ़ाइलों से एक निष्पादन योग्य तक जाने की कुल प्रक्रिया को एक निर्माण के रूप में संदर्भित किया जा सकता है।
संकलन
संकलन स्रोत कोड फ़ाइलों (.c, .cc, या .cpp) के प्रसंस्करण और 'ऑब्जेक्ट' फ़ाइल के निर्माण को संदर्भित करता है। यह कदम कुछ भी नहीं बनाता है जो उपयोगकर्ता वास्तव में चला सकता है। इसके बजाय, कंपाइलर केवल मशीन भाषा निर्देश का उत्पादन करता है जो संकलित स्रोत कोड फ़ाइल के अनुरूप होता है। उदाहरण के लिए, यदि आप तीन अलग-अलग फ़ाइलों को संकलित करते हैं (लेकिन लिंक नहीं करते हैं), तो आपके पास आउटपुट के रूप में बनाई गई तीन ऑब्जेक्ट फाइलें होंगी, जिनमें से प्रत्येक का नाम .o या .obj (एक्सटेंशन आपके कंपाइलर पर निर्भर करेगा)। इन फ़ाइलों में से प्रत्येक में आपके स्रोत कोड फ़ाइल का एक मशीन भाषा फ़ाइल में अनुवाद होता है - लेकिन आप उन्हें अभी तक नहीं चला सकते हैं! आपको उन्हें उन निष्पादन योग्यताओं में बदलना होगा जो आपके ऑपरेटिंग सिस्टम उपयोग कर सकते हैं। यहीं से लिंकर आता है।
लिंक करना
जोड़ना कई ऑब्जेक्ट फ़ाइलों से एक एकल निष्पादन योग्य फ़ाइल के निर्माण को संदर्भित करता है। इस चरण में, यह आम है कि लिंकर अपरिभाषित कार्यों (आमतौर पर, मुख्य रूप से) के बारे में शिकायत करेगा। संकलन के दौरान, यदि कंपाइलर किसी विशेष फ़ंक्शन के लिए परिभाषा नहीं खोज सका, तो यह मान लेगा कि फ़ंक्शन किसी अन्य फ़ाइल में परिभाषित किया गया था। यदि ऐसा नहीं है, तो ऐसा कोई तरीका नहीं है जिससे कंपाइलर को पता चले - यह एक समय में एक से अधिक फ़ाइल की सामग्री को नहीं देखता है। दूसरी ओर, लिंकर, कई फाइलों को देख सकता है और उन कार्यों के लिए संदर्भ खोजने की कोशिश कर सकता है जिनका उल्लेख नहीं किया गया था।
आप पूछ सकते हैं कि अलग संकलन और लिंकिंग चरण क्यों हैं। सबसे पहले, इस तरह से चीजों को लागू करना आसान है। संकलक अपनी बात करता है, और लिंकर अपनी बात करता है - कार्यों को अलग रखने से, कार्यक्रम की जटिलता कम हो जाती है। एक और (अधिक स्पष्ट) लाभ यह है कि यह बड़े कार्यक्रमों के निर्माण की अनुमति देता है बिना संकलन के चरण को हर बार फ़ाइल बदलने के बिना। इसके बजाय, तथाकथित "सशर्त संकलन" का उपयोग करते हुए, केवल उन स्रोत फ़ाइलों को संकलित करना आवश्यक है जो बदल गए हैं; बाकी के लिए, ऑब्जेक्ट फ़ाइलें लिंकर के लिए पर्याप्त इनपुट हैं। अंत में, यह पूर्व-संकलित कोड के पुस्तकालयों को लागू करने के लिए सरल बनाता है: बस ऑब्जेक्ट फ़ाइलें बनाएं और उन्हें किसी अन्य ऑब्जेक्ट फ़ाइल की तरह लिंक करें।
हालत संकलन का पूरा लाभ प्राप्त करने के लिए, शायद यह संभव है कि आपको प्रोग्राम बनाने में मदद करने और याद रखने की तुलना में एक प्रोग्राम मिल जाए, जो आपने पिछले संकलन के बाद से बदल दिया है। (आप, निश्चित रूप से, हर फ़ाइल को फिर से जोड़ सकते हैं जिसमें टाइमस्टैम्प है जो संबंधित ऑब्जेक्ट फ़ाइल के टाइमस्टैम्प से अधिक है।) यदि आप एक एकीकृत विकास वातावरण (आईडीई) के साथ काम कर रहे हैं तो यह आपके लिए पहले से ही इसका ख्याल रख सकता है। यदि आप कमांड लाइन टूल का उपयोग कर रहे हैं, तो एक निफ्टी उपयोगिता है जिसे मेक कहा जाता है जो अधिकांश * निक्स वितरण के साथ आता है। सशर्त संकलन के साथ, इसमें प्रोग्रामिंग के लिए कई अन्य अच्छी विशेषताएं हैं, जैसे कि आपके कार्यक्रम के विभिन्न संकलन की अनुमति देना - उदाहरण के लिए, यदि आपके पास डिबगिंग के लिए वर्बोज़ आउटपुट बनाने वाला संस्करण है।
संकलन चरण और लिंक चरण के बीच के अंतर को जानने से कीड़े के लिए शिकार करना आसान हो सकता है। कंपाइलर त्रुटियां आमतौर पर प्रकृति में वाक्यात्मक होती हैं - एक लापता अर्धविराम, एक अतिरिक्त कोष्ठक। लिंकिंग त्रुटियों को आमतौर पर लापता या कई परिभाषाओं के साथ करना पड़ता है। यदि आपको एक त्रुटि मिलती है कि लिंकर से एक फ़ंक्शन या चर को कई बार परिभाषित किया गया है, तो यह एक अच्छा संकेत है कि त्रुटि यह है कि आपके दो स्रोत कोड फ़ाइलों में समान फ़ंक्शन या चर हैं।
मानक मोर्चे पर:
एक अनुवाद इकाई एक स्रोत फ़ाइलों का संयोजन है, जिसमें हेडर और स्रोत फाइलें शामिल हैं, सशर्त समावेशन पूर्वप्रक्रमक निर्देश द्वारा छोड़ दी गई किसी भी स्रोत लाइनों को कम।
मानक अनुवाद में 9 चरणों को परिभाषित करता है। पहले चार प्रीप्रोसेसिंग के अनुरूप हैं, अगले तीन संकलन हैं, अगले एक टेम्पलेट का तात्पर्य है ( इंस्टेंटेशन इकाइयों का निर्माण ) और अंतिम एक लिंकिंग है।
व्यवहार में आठवें चरण (टेम्पलेट्स का तात्कालिकता) अक्सर संकलन प्रक्रिया के दौरान किया जाता है, लेकिन कुछ संकलक इसे लिंकिंग चरण में देरी करते हैं और कुछ इसे दो में फैलाते हैं।
स्किनी यह है कि एक सीपीयू मेमोरी पतों से डेटा लोड करता है, डेटा को मेमोरी पतों में स्टोर करता है, और प्रोसेस किए गए निर्देशों के अनुक्रम में कुछ सशर्त जंप के साथ निर्देश को मेमोरी पतों से क्रमिक रूप से निष्पादित करता है। निर्देशों की इन तीन श्रेणियों में से प्रत्येक में मशीन अनुदेश में उपयोग किए जाने वाले मेमोरी सेल के लिए एक पते की गणना शामिल है। क्योंकि मशीन निर्देश विशेष रूप से शामिल निर्देश के आधार पर एक चर लंबाई के होते हैं, और क्योंकि हम उनके साथ एक चर लंबाई स्ट्रिंग करते हैं क्योंकि हम अपने मशीन कोड का निर्माण करते हैं, किसी भी पते की गणना और निर्माण में शामिल दो चरण की प्रक्रिया है।
सबसे पहले हम स्मृति के आवंटन को सबसे अच्छे रूप में निर्धारित कर सकते हैं, इससे पहले कि हम यह जान सकें कि वास्तव में प्रत्येक सेल में क्या होता है। हम बाइट्स, या शब्द या जो कुछ भी निर्देश और शाब्दिक और किसी भी डेटा को बनाते हैं, उसका पता लगाते हैं। हम बस मेमोरी को आवंटित करना शुरू करते हैं और उन मूल्यों का निर्माण करते हैं जो कार्यक्रम बनाते हैं जैसा कि हम जाते हैं, और किसी भी स्थान पर ध्यान दें जिसे हमें वापस जाने और एक पते को ठीक करने की आवश्यकता है। उस स्थान पर हमने एक डमी को केवल स्थान को पैड करने के लिए रखा ताकि हम स्मृति आकार की गणना करना जारी रख सकें। उदाहरण के लिए हमारा पहला मशीन कोड एक सेल ले सकता है। अगली मशीन कोड में 3 सेल लग सकते हैं, जिसमें एक मशीन कोड सेल और दो एड्रेस सेल शामिल हैं। अब हमारा पता पॉइंटर 4. है। हम जानते हैं कि मशीन सेल में क्या जाता है, जो ऑप कोड है, लेकिन हमें यह पता लगाने के लिए इंतजार करना होगा कि एड्रेस सेल में क्या जाता है जब तक हम यह नहीं जानते कि वह डेटा कहां स्थित होगा, यानी
अगर वहाँ सिर्फ एक स्रोत फ़ाइल एक संकलक सैद्धांतिक रूप से एक लिंकर के बिना पूरी तरह से निष्पादन योग्य मशीन कोड का उत्पादन कर सकता था। दो पास की प्रक्रिया में यह सभी वास्तविक पतों की गणना किसी भी मशीन लोड या स्टोर निर्देशों द्वारा संदर्भित सभी डेटा कोशिकाओं के लिए कर सकता है। और यह किसी भी पूर्ण कूद निर्देश द्वारा संदर्भित पूर्ण पते की गणना कर सकता है। यह कैसे सरल संकलक है, फोर्थ काम में एक की तरह, कोई लिंकर के साथ।
एक लिंकर कुछ ऐसा है जो कोड के ब्लॉक को अलग से संकलित करने की अनुमति देता है। यह बिल्डिंग कोड की समग्र प्रक्रिया को गति प्रदान कर सकता है, और कुछ लचीलेपन की अनुमति देता है कि कैसे बाद में ब्लॉक का उपयोग किया जाता है, दूसरे शब्दों में उन्हें मेमोरी में स्थानांतरित किया जा सकता है, उदाहरण के लिए 1000 तक हर पते को जोड़ने के लिए ब्लॉक 1000 एड्रेस सेल द्वारा स्कूटर।
तो कंपाइलर आउटपुट क्या होता है यह रफ मशीन कोड है जो अभी तक पूरी तरह से निर्मित नहीं है, लेकिन यह निर्धारित किया गया है ताकि हम हर चीज के आकार को जान सकें, दूसरे शब्दों में तो हम गणना करना शुरू कर सकते हैं कि सभी पूर्ण पते कहां स्थित होंगे। संकलक प्रतीकों की एक सूची भी तैयार करता है जो नाम / पता जोड़े हैं। प्रतीक एक नाम के साथ मॉड्यूल में मशीन कोड में एक मेमोरी ऑफसेट से संबंधित हैं। मॉड्यूल में प्रतीक की स्मृति स्थान के लिए पूर्ण दूरी होने वाली ऑफसेट।
यहीं से हमें लिंकर मिलता है। लिंकर पहले मशीन कोड के इन सभी ब्लॉकों को एक साथ खत्म करने के लिए थप्पड़ मारता है और जहां प्रत्येक शुरू होता है, नीचे नोट करता है। तब यह एक मॉड्यूल के भीतर सापेक्ष ऑफसेट और बड़े लेआउट में मॉड्यूल की पूर्ण स्थिति को एक साथ जोड़कर तय किए जाने वाले पतों की गणना करता है।
जाहिर है मैंने इसे ओवरसिम्प्लीफाई किया है ताकि आप इसे समझ सकें, और मैंने जानबूझकर ऑब्जेक्ट फाइल्स, सिंबल टेबल आदि के शब्दजाल का इस्तेमाल नहीं किया है, जो मेरे लिए भ्रम का हिस्सा है।
GCC 4 चरणों में निष्पादन योग्य में C / C ++ प्रोग्राम संकलित करता है।
उदाहरण के लिए, gcc -o hello hello.cनिम्न प्रकार से किया जाता है:
जीएनयू सी प्रीप्रोसेसर ( cpp.exe) के माध्यम से प्रीप्रोसेसिंग , जिसमें हेडर ( #include) शामिल हैं और मैक्रोज़ ( #define) का विस्तार करता है ।
cpp hello.c > hello.i
परिणामी मध्यवर्ती फ़ाइल "hello.i" में विस्तारित स्रोत कोड होता है।
कंपाइलर एक विशिष्ट प्रोसेसर के लिए प्री-प्रोसेस्ड सोर्स कोड को असेंबली कोड में संकलित करता है।
gcc -S hello.i
ऑब्जेक्ट कोड के बजाय -S विकल्प असेंबली कोड का उत्पादन करने के लिए निर्दिष्ट करता है। परिणामी असेंबली फ़ाइल "hello.s" है।
असेंबलर ( as.exe) असेंबली कोड को ऑब्जेक्ट फ़ाइल "hello.o" में मशीन कोड में परिवर्तित करता है।
as -o hello.o hello.s
अंत में, लिंकर ( ld.exe) एक निष्पादन योग्य फ़ाइल "हैलो" का उत्पादन करने के लिए ऑब्जेक्ट कोड को लाइब्रेरी कोड के साथ जोड़ता है।
ld -o hello hello.o ... लाइब्रेरी ...
URL देखें: http://facademy.cs.niu.edu/~mcmahon/CS241/Notes/compile.html
C ++ की पूर्ण संकलन प्रक्रिया इस URL में स्पष्ट रूप से प्रस्तुत की गई है।