दिलचस्प पोस्ट
एक जेनेरिक तरीकों पर एकाधिक वाइल्डकार्ड जावा संकलक (और मुझे!) बहुत ही भ्रमित हैं एकाधिक क्षेत्रों पर एमवीसी फॉर्म सत्यापन OS X पर ब्रॉड, नोड.जेएस, io.js, nvm, npm को स्थापित करने का सुझाव दिया गया उपाय क्या है? Openssl एक आंतरिक या बाहरी कमान के रूप में मान्यता प्राप्त नहीं है रेल 3: अजाक्स कॉल में "redirect_to" कैसे करें? स्ट्रिंग के रूप में enum के JSON क्रमांकन ListView पर अंतहीन स्क्रॉल कार्यान्वित सर्वश्रेष्ठ जावा ओब्बुस्केटेक्टर? तर्क के साथ PHP array_filter ओरिएंटेशन परिवर्तन पर एंड्रॉइड टुकड़ा जीवनचक्र आईओएस 7 स्टेटस बार ओवरलैपिंग यूआई कोलेक्शन की गणना करें – कोर () – कॉलम के केवल एक उप-भाग के लिए वादा के बीच में कोई अंतर है। तो.पहले बनाम वादा। तब; वादा करता हूँ। समूह की चाबी से हैश और मूल्यों का योग ACTION_SEND के माध्यम से एंड्रॉइड ऐप से फेसबुक पर टेक्स्ट साझा करें

साझा पुस्तकालयों में अपरिभाषित संदर्भों के बारे में सूचित करने के लिए जीसीसी को बल दें

मेरे पास एक साझा लाइब्रेरी है जो किसी अन्य (तृतीय-पक्ष) साझा लाइब्रेरी से जुड़ा हुआ है। मेरी साझा लाइब्रेरी तब मेरे आवेदन में dlopen का उपयोग करके भरी हुई है। यह सब ठीक काम करता है (संभालने फ़ाइलें उचित पथ आदि में हैं)

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

अगर मैं अपनी लाइब्रेरी (अस्थायी रूप से) निष्पादन योग्य होने के लिए बदलता हूं, तो मुझे अपरिभाषित संदर्भ मिलते हैं (लिंकर को लाइब्रेरी की आपूर्ति न करते हुए)। (अगर मैं इसे निर्दिष्ट करता है तो ठीक काम करता है।)

यानी, निम्नलिखित किया गया है:

g++ -fPIC -shared -o libb.so bo g++ -fPIC -shared -o liba.so ao g++ -o a.exe a.cpp 

जहां दूसरी पंक्ति कोई त्रुटि नहीं देती है और तीसरी पंक्ति एक अनिर्धारित संदर्भ के बारे में शिकायत करती है।

नमूना कोड:

आह:

 class a { public: void foobar(); }; 

a.cpp:

 #include "ah" #include "bh" void a::foobar() { b myB; myB.foobar(); } int main() { a myA; myA.foobar(); } 

bh:

 class b { public: void foobar(); }; 

b.cpp:

 #include "bh" void b::foobar() { } 

Solutions Collecting From Web of "साझा पुस्तकालयों में अपरिभाषित संदर्भों के बारे में सूचित करने के लिए जीसीसी को बल दें"

– डब्लूएल, – बिना-अपरिभाषित लिंकर विकल्प का उपयोग साझा लाइब्रेरी के निर्माण के दौरान किया जा सकता है, अनिर्धारित प्रतीकों को लिंकर त्रुटियों के रूप में दिखाया जाएगा।

जी ++ -shared -Wl, -सोमा, libmylib.so.5 -Wl, – नो-अपरिभाषित-ओ libmylib.so.1.1 mylib.o -lthirdpartylib

अधिक शोध के बाद, मुझे एहसास हुआ कि सामान कैसे काम करता है साझा लाइब्रेरी के अनिर्धारित प्रतीकों को हेरफेर करने के लिए दो लिंकर विकल्प हैं:

पहले एक --no-undefined यह अनसुलझे प्रतीकों की रिपोर्ट करता है जिन्हें तुरंत चरणबद्ध तरीके से हल नहीं किया जाता है। जब तक कि कोई साझा लाइब्रेरी में मैन्युअल रूप से ( libgcc_s स्विच) या स्वचालित रूप से ( libgcc_s , C ++ रनटाइम; libgcc_s , सी रनटाइम; ld-linux-**.so , डायनेमिक लिंकर यूटीएल) चुना हुआ लिंक मिला है --no-undefined यह त्रुटि के रूप में रिपोर्ट करता है यही महत्वपूर्ण प्रश्नकर्ता की आवश्यकता है

एक अन्य महत्वपूर्ण, --no-allow-shlib-undefined (जिसका विवरण भी सुझाता है --no-undefined भी --no-undefined )। यह जांचता है कि क्या साझा लाइब्रेरी में परिभाषाएं जो आप के साथ अपनी साझा लाइब्रेरी लिंक करते हैं, संतुष्ट हैं। इस विषय में दिखाए गए मामले में यह कुंजी बहुत कम उपयोग है, लेकिन यह उपयोगी हो सकता है। हालांकि, इसकी अपनी बाधाएं हैं

मैनपैकेज कुछ कारण बताता है कि यह डिफ़ॉल्ट क्यों नहीं है:

  --allow-shlib-undefined --no-allow-shlib-undefined Allows (the default) or disallows undefined symbols in shared libraries (It is meant, in shared libraries _linked_against_, not the one we're creating!--Pavel Shved). This switch is similar to --no-un- defined except that it determines the behaviour when the undefined symbols are in a shared library rather than a regular object file. It does not affect how undefined symbols in regular object files are handled. The reason that --allow-shlib-undefined is the default is that the shared library being specified at link time may not be the same as the one that is available at load time, so the symbols might actually be resolvable at load time. Plus there are some systems, (eg BeOS) where undefined symbols in shared libraries is normal. (The kernel patches them at load time to select which function is most appropri- ate for the current architecture. This is used for example to dynam- ically select an appropriate memset function). Apparently it is also normal for HPPA shared libraries to have undefined symbols. 

बात यह है कि ऊपर क्या कहा गया है, उदाहरण के लिए, लिनक्स सिस्टम के लिए, जहां साझा लाइब्रेरी के कुछ आंतरिक रूटीन को ld-linux.so लिनक्स में लागू किया जाता है। इसलिए, गतिशील लोडर (यह दोनों निष्पादन योग्य और साझा लाइब्रेरी है)। जब तक आप इसे किसी तरह से लिंक नहीं करेंगे, आपको ऐसा कुछ मिलेगा:

 /lib64/libc.so.6: undefined reference to `_dl_argv@GLIBC_PRIVATE' /lib64/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE' /usr/lib64/gcc/x86_64-suse-linux/4.3/libstdc++.so: undefined reference to `__tls_get_addr@GLIBC_2.3' /lib64/libc.so.6: undefined reference to `_rtld_global@GLIBC_PRIVATE' /lib64/libc.so.6: undefined reference to `__libc_enable_secure@GLIBC_PRIVATE' 

ये लोडर से अनिर्धारित संदर्भ हैं, ld-linux.so यह प्लेटफ़ॉर्म-विशिष्ट है (उदाहरण के लिए, मेरे सिस्टम पर सही लोडर /lib64/ld-linux-x86-64.so )। आप अपनी लाइब्रेरी के साथ लोडर को लिंक कर सकते हैं और ऊपर दिखाए गए मुश्किल संदर्भ भी देख सकते हैं:

 g++ -fPIC -shared -o liba.so ao -Wl,--no-allow-shlib-undefined /lib64/ld-linux-x86-64.so.2 

इसके बारे में मैनड्रिव विकी पर एक अच्छी चर्चा भी है।

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