2009-04-07 26 views
9

एक तीसरे पक्ष ने मुझे सौरिस स्टेशन से जोड़ने के लिए एक स्थिर lib (.a) प्रदान किया। मैंने सनप्रो के साथ संकलन करने की कोशिश की, और लिंक चरण में विफल रहा।क्या यह जानने का कोई तरीका है कि किस कंपाइलर ने स्थिर पुस्तकालय बनाया है?

मुझे लगता है कि यह समस्या मेरे द्वारा उपयोग किए जाने वाले कंपाइलर (जीसीसी के बजाय?) या बस इसके संस्करण से आ रही है (क्योंकि कंपाइलर द्वारा प्रदान की गई एसडीडी लिब लाइब्रेरी द्वारा अपेक्षित संस्करण से बदल सकती है AFAIK यह लिंक पर त्रुटियों का कारण बन सकती है कदम)।

मुझे कैसे पता चलेगा कि इस कंपाइलर को उत्पन्न करने के लिए किस कंपाइलर का उपयोग किया गया था? क्या ऐसा कुछ उपकरण कर रहे हैं? सनप्रो/जीसीसी या कुछ भी में कुछ विकल्प?

एक संकेत के रूप में: मैं कुछ समय पहले कि compilers अलग mangling परंपराओं का उपयोग जब वस्तु फ़ाइलों पैदा पढ़ा है (सच?)। फिर भी, "एनएम - डेमंगल" कमांड लाइन मुझे इस स्थिर lib में डीबग प्रतीकों से सभी फ़ंक्शन नामों को अच्छी तरह प्रिंट करता है। यह कैसे काम करता है ? अगर मेरी धारणा ठीक है, एनएम एक स्थिर पुस्तकालय में कौन सा सम्मेलन उपयोग में है, यह हल करने का कोई तरीका है, है ना? या क्या इसका मतलब यह है कि जीएनयू जीसीसी द्वारा लिब उत्पन्न किया गया था, क्योंकि एनएम जीएनयू बिनुटिल्स का हिस्सा है?

मैं अपने कार्य केंद्र के करीब रहा हूँ नहीं तो मैं लिंकर से & पेस्ट त्रुटि उत्पादन कॉपी नहीं कर सकते (पल के लिए नहीं लेकिन मैं उन्हें एक और संपादन में नकल कर सकता है)

+1

आप "तीसरी पार्टी" से क्यों नहीं पूछते हैं जिसने पुस्तकालय को इसका उपयोग करने के निर्देशों के लिए आपूर्ति की है? –

+0

मैंने उनसे पूछा। लेकिन उनकी सहायता टीम से कोई जवाब नहीं है, जो देव टीम से पूछने में अनिच्छुक है, ऐसा लगता है ...:/ –

उत्तर

2

मैं ('-a' विकल्प, या अपने खुद के संस्करण जहां '-a के व्यवहार मानक है) के साथ strings प्रोग्राम का उपयोग और बताना कहानी लक्षण देखने के लिए करते हैं। उदाहरण के लिए, अपने खुद के पुस्तकालयों में से एक में, मुझे लगता है:

/work1/gcc/v4.2.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.2.3/include 
/work1/gcc/v4.3.0/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.0/include 
/work1/gcc/v4.3.1/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.1/include 
/work1/gcc/v4.3.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.3/include 

पता चलता है कि कि पुस्तकालय में कोड वर्षों (वास्तव में की अवधि में जीसीसी के संस्करणों की एक किस्म के साथ संकलित किया गया है, मैं काफी हूँ एक पुस्तकालय में इतने सारे संस्करण खोजने के लिए चौंका दिया)।

एक और पुस्तकालय शामिल हैं:

cg: Sun Compiler Common 11 Patch 120760-06 2006/05/26 
acomp: Sun C 5.8 Patch 121015-02 2006/03/29 
iropt: Sun Compiler Common 11 Patch 120760-06 2006/05/26 
/compilers/v11/SUNWspro/prod/bin/cc -O -v -Xa -xarch=v9 ... 

तो, वहां आम तौर पर कर रहे हैं यह दर्शाता है जो संकलक इस्तेमाल किया गया था वस्तु फ़ाइलों में उंगलियों के निशान। लेकिन आपको पता होना चाहिए कि उन्हें कैसे देखना है।

-1

आप यूनिक्स उपयोगिता कोशिश कर सकते हैं फ़ाइल:

file foo.a 
+0

मैंने कोशिश की लेकिन मुझे याद है कि यह केवल मुझे बताता है कि यह फ़ाइल SPARC मंच के लिए ईएलएफ प्रारूप का उपयोग करती है। क्या सनप्रो ईएलएफ प्रारूप उत्पन्न करता है, जैसा कि जीसीसी करता है? –

+0

'फ़ाइल' उपकरण शायद ही कभी संकलक के बारे में जानकारी वापस करेगा! – Enzo

2

पुस्तकालय एक सी या सी ++ पुस्तकालय होना चाहिए है?

यदि यह एक सी पुस्तकालय है तो नाम मैंगलिंग समस्या नहीं हो सकती है, क्योंकि सी में कोई भी नहीं है। हालांकि यह गलत प्रारूप में हो सकता है। a.out प्रारूप में पुस्तकालयों के लिए उपयोग की जाने वाली इकाइयां लेकिन लगभग सभी नए संस्करण ELF जैसे अधिक शक्तिशाली प्रारूपों में स्विच किए गए।

यदि यह एक सी ++ लाइब्रेरी है तो नाम मैंगलिंग एक मुद्दा हो सकता है। अधिकांश कंपाइलर कुछ प्रतीकों को एम्बेड करते हैं जो कोड में विशिष्ट कंपाइलर होते हैं, इसलिए यदि आपके पास एनएम जैसे टूल हैं जो प्रतीकों को सूचीबद्ध करने के लिए हैं, तो आप उम्मीद कर सकते हैं कि यह किस संकलक से आया है।

उदाहरण जी के लिए ++ एक प्रतीक

__gxx_personality_v0

उस में

पुस्तकालयों

4

संग्रह से ऑब्जेक्ट फ़ाइलें निकालें तो पर उन्हें (में से कुछ पर strings आदेश चला पहले है बनाता है छोटे से क्योंकि वहां से कम शोर होगा)। कई कंपाइलर्स ऑब्जेक्ट फ़ाइलों में ASCII हस्ताक्षर सम्मिलित करते हैं।

उदाहरण के लिए, निम्नलिखित व्यर्थ स्रोत फ़ाइल, foo.c:

extern void blah(); 

जब एक 647 बाइट foo.o वस्तु फ़ाइल में के माध्यम से gcc -c -o foo.o foo.c परिणाम foo.o में मेरी फेडोरा 10 मशीन पर संकलित।

GCC: (GNU) 4.3.2 20081105 (Red Hat 4.3.2-7) 
.symtab 
.strtab 
.shstrtab 
.text 
.data 
.bss 
.comment 
.note.GNU-stack 
foo.c

जो यह स्पष्ट संकलक जीसीसी था बनाता में पर foo.o परिणाम strings चल रहा है। यहां तक ​​कि अगर मैं इसे -fno-ident के साथ संकलित करता हूं, तो भी जीएनयू-स्टैक नोट ईएलएफ अनुभाग मौजूद होगा।

आप ar सुविधा का उपयोग, या आधी रात के कमांडर (जो ar एकीकृत) का उपयोग कर वस्तु फ़ाइलों को अलग कर सकते हैं, या आप बस संग्रह पर strings (जो आप अधिक शोर देने के लिए और कम प्रासंगिक हो सकता है चला सकते हैं, लेकिन अभी भी मदद मिलेगी ।)

+0

या लाइब्रेरी पर सीधे 'तार' चलाएं - पहले ऑब्जेक्ट फ़ाइलों को निकालने की आवश्यकता नहीं है। –

+0

जैसा मैंने उल्लेख किया है, वहां बहुत अधिक आउटपुट है, * विशेष रूप से * सी ++ ऑब्जेक्ट फाइलों के मामले में, और कंपाइलर हस्ताक्षर याद करना बहुत आसान है। इसके अलावा, कोई आवश्यकता नहीं है कि एक संग्रह में सभी ऑब्जेक्ट एक ही कंपाइलर से हों ... –

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

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