जीसीसी/जी ++

पर पुस्तकालयों को निर्दिष्ट करने के विभिन्न तरीके मुझे समझने में उत्सुकता होगी कि पुस्तकालयों (दोनों साझा और स्थैतिक) को निम्नलिखित दो तरीकों से जीसीसी/जी ++ में निर्दिष्ट करने में कोई महत्वपूर्ण अंतर है (सीसी जी ++ या जीसीसी हो सकता है)जीसीसी/जी ++

CC -o output_executable /path/to/my/libstatic.a /path/to/my/libshared.so source1.cpp source2.cpp ... sourceN.cpp

बनाम

CC -o output_executable -L/path/to/my/libs -lstatic -lshared source1.cpp source2.cpp ... sourceN.cpp

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

एंड्रिया।

स्रोत

2010-03-29 abigagli

क्या आपने परिणामी निष्पादन योग्य फ़ाइलों दोनों की तुलना की और तुलना की है? – Ernelli

वास्तव में नहीं। हो सकता है कि मेरा अगला परीक्षण हो, भले ही मैं यह देखना चाहूंगा कि इस – abigagli

ठीक है, मैं अपने आप को कुछ प्रयोगों के आधार पर जवाब देने और जीसीसी प्रलेखन का एक गहरी पढ़ने कर सकते हैं:

जीसीसी प्रलेखन से: http://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

[...] लिंकर स्कैनिंग द्वारा एक संग्रह फ़ाइल हैंडल इसके माध्यम से उन सदस्यों के लिए जो प्रतीकों को परिभाषित करते हैं जिन्हें अभी तक संदर्भित किया गया है लेकिन परिभाषित नहीं किया गया है। लेकिन अगर पाया गया फ़ाइल एक साधारण ऑब्जेक्ट फ़ाइल है, तो यह सामान्य फैशन में जुड़ा हुआ है। एक -l विकल्प का उपयोग कर और एक फ़ाइल नाम निर्दिष्ट के बीच फर्क सिर्फ इतना है कि -l lib' and .एक साथ पुस्तकालय के चारों ओर 'और खोज कई निर्देशिकाओं

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

स्रोत

2010-03-30 08:57:11 abigagli

के बारे में कुछ "आधिकारिक" जानकारी है, तो पूर्ण पथ का उपयोग करते समय .so - एक अलग वातावरण पर रनटाइम के दौरान क्या होता है? एसएसओ कैसे दिख रहा है? ऐसा लगता है कि इसकी पूरी लाइब्रेरी लाइब्रेरी के रूप में खोज रही है, इसलिए यदि यह लक्षित वातावरण में मूल सटीक स्थान के भीतर मौजूद नहीं है - यह नहीं मिल सकता है .. इसे कैसे दूर किया जाए? –

सामान्य रूप से क्या होता है, यदि .so में "soname" है (यानी एक प्रमुख संस्करण संख्या के साथ लाइब्रेरी का नाम), यह है कि "soname" निष्पादन योग्य में निर्भरता के रूप में पंजीकृत है। फिर जब निष्पादन योग्य रनटाइम लिंकर (आमतौर पर linux पर /lib/ld-linux.so.X) शुरू होता है तो विभिन्न स्थानों (प्लेटफॉर्म द्वारा निर्धारित, एलडी_LIBRARY_PATH पर्यावरण चर और संभावित रूप से भवन के दौरान उपयोग किए जाने वाले आरपीएथ तर्क) में देखेंगे soname (जो आमतौर पर फाइल सिस्टम पर .so असली नाम के लिए एक सिम्लिंक है)। यह भी देखें http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html – abigagli

धन्यवाद! कुछ घंटों पहले खुद को पता चला और rpath :) –

जीसीसी/जी ++

उत्तर

संबंधित मुद्दे