2012-09-13 45 views
5

एक प्रोजेक्ट में, मेरे सहयोगी एक स्थिर पुस्तकालय बनाते हैं, उदाहरण के लिए liba.a, जो ऐप से जुड़ा हुआ है।मैं libc.a को बांह-लिनक्स उपयोग में साझा लाइब्रेरी में कैसे साझा कर सकता हूं arm-none-linux-gnueabi-gcc

liba.a में वह libc malloc() को अपने स्वामी संस्करण में ओवरराइट करता है।

मैं एक साझा लाइब्रेरी libs.so बनाता हूं जो ऐप से भी जुड़ा हुआ है।

समस्या यह है कि जब मेरी libs.so ऐप के साथ जुड़ा हुआ है, तो मेरी libs.so में इस्तेमाल किया जाने वाला malloc() liba.a, में मानक libc.so में से एक नहीं होगा, इससे समस्याएं पैदा होती हैं।

फिर, मैं libc.a को मेरी libs.so पर स्थिर लिंक चाहता हूं, मैंने जीसीसी के लिए -स्टिक-शेर-एफपीआईसी झंडे का उपयोग किया।

लेकिन मुझे हमेशा हाथ-2012.03/बिन /../ lib/gcc/arm-none-linux-gnueabi/4.6.3 /../../../../ arm-none-linux मिलता है -gnueabi/bin/ld: arm-2012.03/bin /../ arm-none-linux-gnueabi/libc/usr/lib/libc.a (dl-tsd.o) (। text + 0x14): R_ARM_TLS_LE32 स्थानांतरण नहीं साझा वस्तु में अनुमति दी।

क्या किसी के बारे में कोई विचार है?

धन्यवाद आगे।

+0

मुझे लगता है -स्टैटिक -शेयर को मिश्रित नहीं किया जाना चाहिए .... – Jeyaram

+0

निम्नलिखित पाठ को ld.pdf से कोडगर्गेरी से कॉपी किया गया है: "-स्टैटिक साझा पुस्तकालयों के खिलाफ लिंक न करें। यह केवल प्लेटफॉर्म पर सार्थक है जिसके लिए साझा किया गया है पुस्तकालयों का समर्थन किया जाता है। ** यह विकल्प '-shared' ** के साथ उपयोग किया जा सकता है। ऐसा करने का अर्थ है कि साझा लाइब्रेरी बनाई जा रही है, लेकिन सभी लाइब्रेरी के बाहरी संदर्भों को स्थिर पुस्तकालयों से प्रविष्टियों में खींचकर हल किया जाना चाहिए । " –

+0

@ डेविड कही: केवल यही कहता है- स्टेटिक और शेर मिश्रित किया जा सकता है, लेकिन यह नहीं कि यह एक अच्छा विचार है। सामान्यतः कंपाइलर्स में कई विकल्प होते हैं जो सामान्य अनुप्रयोगों के लिए उपयोग करने के लिए एक अच्छा विचार नहीं हैं। वे कर्नेल, बूटलोडर, माइक्रोकंट्रोलर कोड और इस तरह के संकलन जैसे विशेष मामलों के लिए महत्वपूर्ण हैं। –

उत्तर

2

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

मत करो। गतिशील पुस्तकालयों को गतिशील रूप से सिस्टम पुस्तकालयों के खिलाफ लिंक करना होगा और किसी भी गतिशील पुस्तकालयों के खिलाफ लिंक करने वाले किसी निष्पादन योग्य को भी गतिशील रूप से सिस्टम पुस्तकालयों को लिंक करना होगा।

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

+0

@Hudec: कृपया अपनी याद दिलाने के लिए धन्यवाद। मेरे सहयोगी ने libc.so में मानक malloc() का उपयोग करने के लिए अपनी लाइब्रेरी बदल दी है। लेकिन सिर्फ उत्सुकता के लिए, पीसी जीसीसी में निम्नलिखित उदाहरण क्यों काम किया, लेकिन एआरएम जीसीसी में असफल रहा: $ cat libtest.c '# शामिल शून्य foo() {printf ("% d \ n ", 42); } ' $ बिल्ली मुख्य।सी '# शामिल बाहरी शून्य foo(); int मुख्य() {puts ("जवाब है:"); foo(); } ' ' gcc -shared -fPIC libtest.c -o libtest.so -static-libgcc -Wl, -Bstatic -lc && gcc -c main.c -o main.o && gcc main.o -o test। /libtest.so && LD_PRELOAD =।/libtest.so।/test' ====> 42, काम किया। –

+0

@Hudec: मुझे यह जानकारी कहां मिल सकती है? _Don't। गतिशील पुस्तकालयों को गतिशील रूप से सिस्टम पुस्तकालयों के खिलाफ लिंक करना होगा और किसी भी गतिशील पुस्तकालयों के खिलाफ लिंक करने वाले किसी भी निष्पादन योग्य को सिस्टम लाइब्रेरी को गतिशील रूप से लिंक करना होगा ._ और libc.a के लिए क्या उपयोग किया जाता है? –

+0

@ डेविड कही: यह उस विशेष प्रणाली पर libc.a पर निर्भर करता है जिस पर आप वास्तव में कोशिश कर रहे हैं। यह एक विशेष स्थापना पर काम कर सकता है, न कि किसी अन्य पर। कई प्रतिष्ठानों में स्थिर libc भी स्थापित नहीं है। –