Glibc को GCC से अलग क्यों रखा गया है?

Question

GCC C कंपाइलर है। Glibc C लाइब्रेरी है। हालांकि, यह एक संकलक और मानक पुस्तकालय के लिए एक सी कार्यान्वयन के रूप में बंडल के लिए एक पूर्ण आवश्यकता नहीं है?

उदाहरण के लिए, सी पुस्तकालय की तरह ABI और संकलक विशिष्ट सामान शामिल हैं <limits.h>, <stdint.h>आदि, जो संकलनकर्ता और एपीआई के बीच अलग है। और "मुख्य फ़ंक्शन को कैसे कॉल करें" जैसे विवरण भी संकलक पर निर्भर करते हैं, लेकिन वास्तव में उन विवरणों को libc.soएक लिनक्स सिस्टम द्वारा आपूर्ति की जाती है । उदाहरण के लिए, यदि मैं किसी अन्य एबीआई के साथ काम करने के लिए कंपाइलर को बदल देता हूं, जैसे int8 बाइट्स के साथ उपयोग करने पर, सी लाइब्रेरी अब काम नहीं करेगी क्योंकि सामान <limits.h>गलत हो जाएगा।

Answer 1

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

लिनक्स पर भी, आपके पास C मानक पुस्तकालय हो सकता है जो GNU Glibc नहीं है । विशेष रूप से, आप जीसीसी का निर्माण कर सकते हैं (या इसका इस्तेमाल) के साथ Linux सिस्टम पर musl-libc या साथ बायोनिक (एंड्रॉयड सिस्टम) या साथ dietlibc , आदि और एक Linux सिस्टम जीएनयू Glibc हो सकता था और (जैसे कुछ अन्य सी संकलक उपयोग बजना या टाइनीसीसी)।

साथ ही, C लाइब्रेरी लिनक्स कर्नेल पर बहुत अधिक निर्भर करती है। कर्नेल के कुछ पुराने संस्करणों को कुछ विशेष प्रकार (या संस्करण) की आवश्यकता हो सकती हैlibc

और जीसीसी एक क्रॉस-कंपाइलर के रूप में निर्माण योग्य है ।

और " mainफ़ंक्शन कैसे कॉल करें" जैसे विवरण भी कंपाइलर पर निर्भर करते हैं, लेकिन वास्तव में, उन विवरणों को libc.soलिनक्स सिस्टम द्वारा आपूर्ति की जाती है ।

यह बिल्कुल सही नहीं है। mainसमारोह से पुकारा जाता है (एक की मेजबानी की स्थिति में) crt0 सामान, जिनमें से कुछ जीसीसी द्वारा प्रदान की जाती है (उदाहरण के लिए /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.oपर मेरे Debian / सिड / x86-64 से है libgcc-6-devपैकेज)। इसके बारे में भी पढ़ेंlibgcc

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

^{(इसलिए GCC डेवलपर्स और GNU libc डेवलपर्स को बातचीत करनी होगी)}

.... अगर मैं एक और ABI के साथ काम करने के लिए कंपाइलर बदलूं ...

आपको ... /configureGCC कंपाइलर और इसे फिर से बनाना होगा, और आपको GCC कंपाइलर (अपने ABI और कॉलिंग कन्वेंशन का वर्णन करने के लिए) पैच करना पड़ सकता है । X32 ABI एक अच्छा उदाहरण है।

अंत में, GCC के कुछ योगदानकर्ताओं या अनुरक्षकों (मेरे सहित) ने एक कॉपीराइट असाइनमेंट पर हस्ताक्षर किए हैं जो GCC को कवर करता है लेकिन GNU को नहीं glibc।

^{(जीसीसी लाइसेंस के बारे में, ध्यान से पढ़ें जीसीसी रनटाइम लाइब्रेरी अपवाद )}

ध्यान दें कि कुछ मानक हेडर, जैसे कि <limits.h>या <stdint.h>जीसीसी द्वारा प्रदान किए गए हैं; अन्य, जैसे <stdlib.h>GCC बिल्ड के दौरान "फिक्स्ड" हैं: कंपाइलर बिल्ड प्रक्रिया उन्हें Libc कार्यान्वयन से लेती है और उन्हें पैच करती है। फिर भी, अन्य मानक हेडर (शायद <stdio.h>और आंतरिक हेडर इसमें शामिल हैं) से लिया गया है libc। GCC FIXINCLUDES और फिक्स्ड हैडर फ़ाइलों के बारे में और पढ़ें ।

^{(फिक्की की बात कुछ ऐसी है जिसे मैं (बेसिल) अभी भी अच्छी तरह से नहीं समझता हूं)}

आप gcc -v -Hअधिक सटीक रूप से समझने के लिए संकलित कर सकते हैं कि कौन से वास्तविक कार्यक्रम चलाए जा रहे हैं (चूंकि gccएक ड्राइवर है, cc1कंपाइलर को चलाने वाला , ld& collect2लिंकर्स, asअसेंबलर, आदि ...) और कौन से हेडर शामिल हैं, कौन सी लाइब्रेरी और ऑब्जेक्ट फाइलें जुड़ी हुई हैं (यहां तक ​​कि संक्षेप में , सी मानक पुस्तकालय और crt0 सहित )। GCC विकल्पों के बारे में और पढ़ें ।

BTW, आप एक C मानक लाइब्रेरी का उपयोग कर सकते हैं, जिसे आपके GCC के किसी एक एक्सपेक्टेशन से अलग किया गया हो musl-libcया (जैसे या कुछ डाइटलिबक ) के लिए बनाया गया हो , उपयुक्त अतिरिक्त तर्कों को दरकिनार कर gcc...

Comments

सही उत्तर, भले ही एक सही डिज़ाइन न हो। यही कारण है कि MSVC ++ 2011 के पूर्व / 2011 के ऑपरेटिंग सिस्टम के लिए C ++ 11 / C ++ 14 कोड को संकलित कर सकता है, लेकिन GCC आमतौर पर नहीं कर सकता।

— MSalters 9'17

"सही डिजाइन नहीं" से आपका क्या मतलब है? और मुझे यकीन नहीं है कि जीसीसी पुराने ओएस के लिए सी ++ 14 कोड को संकलित नहीं कर सकता है (हालांकि, आपको उस पुराने ओएस पर हाल के जीसीसी को संकलित करने की आवश्यकता हो सकती है)।

— बेसिल स्टेयरनेविच

आईएसओ सी के अनुसार, सी स्टैंडर्ड लाइब्रेरी कंपाइलर का हिस्सा है। वही C ++ लाइब्रेरी के लिए है। अब समस्या यह है कि नए जीसीसी संस्करण के साथ निर्मित अनुप्रयोगों में ओएस के ग्लिबक पर एक निर्भरता होगी जहां वे निर्मित होते हैं, जो लक्ष्य प्रणाली पर ग्लिबैक की तुलना में नया हो सकता है। एक बेहतर समाधान संभवत: उस पर निर्भर होगा gcclibcजो ओएस पुस्तकालयों पर बनाता है, लेकिन जीसीसी के हिस्से के रूप में संस्करणबद्ध किया गया है न कि ओएस पर।

— MSalters

क्या आप सुनिश्चित हैं कि C11 या C ++ 14 मानकों में "संकलक" शब्द का उल्लेख है? AFAIU वे "कार्यान्वयन" की बात करते हैं (जो कि एक सॉफ्टवेयर भी नहीं हो सकता है)

— बेसिल स्टायरनेविच

कुछ हेडर, जैसे <stdint.h>या <limits.h>वास्तव में जीसीसी द्वारा प्रदान किए जाते हैं। अन्य हेडर, जैसे <stdlib.h>सी लाइब्रेरी से लिया गया और जीसीसी बिल्ड के दौरान "निश्चित"।

— बेसिल स्टारीनेविच

Answer 2

संक्षिप्त उत्तर यह है कि यदि दोनों को एक साथ 'बंडल' किया जाता है, तो glibc को GPL * के तहत लाइसेंस दिया जाएगा, और इसलिए यह मालिकाना परियोजनाओं के लिए पूरी तरह से अनुपयुक्त होगा। जबकि FSF और GNU परियोजना का मालिकाना सॉफ्टवेयर के लिए कोई प्रेम नहीं है, glibc को LGPL को GCC को अपनाने और मुफ्त सॉफ्टवेयर पारिस्थितिकी तंत्र को आगे बढ़ाने के लिए एक रणनीतिक विकल्प के रूप में लाइसेंस दिया गया था। GCC वास्तव में GPL के तहत एक विशिष्ट रनटाइम लिंकिंग अपवाद के साथ लाइसेंस प्राप्त है, क्योंकि स्थिति कुछ मैला है। glibc को समझदार साझा-पुस्तकालय स्थितियों की अनुमति देने के लिए LGPL के प्रति लाइसेंस प्राप्त है।

https://www.gnu.org/licenses/gcc-exception-faq.html

इसके अतिरिक्त, glibc में सभी प्रकार के शिम और अन्य घटक होते हैं, जो इसे अलग-अलग ऑपरेटिंग सिस्टम के लिए अनुकूलित करते हैं, और वितरण करते हैं कि gcc के समान पैकेज भी चीजों को गड़बड़ कर देगा।

* वैकल्पिक रूप से, जीसीसी को कुछ अन्य जीपीएल के तहत लाइसेंस दिया जा सकता है, हालांकि उस पर एफएसएफ के विचार "मेरे मृत शरीर पर" की तर्ज पर होंगे।

Comments

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

— डॉक ब्राउन

जीक्यूएल के तहत होने के लिए जीसीसी और ग्लिबक को एक साथ बांधने के लिए बाध्य क्यों किया जाएगा? मेरी समझ यह थी कि बंडल एक "संयुक्त कार्य" नहीं है, इसलिए जीपीएल सीमा पार नहीं करता है। संपादित करें: डॉक्टर ब्राउन ने क्या कहा :-)

— फिलिप केंडल