2012-03-26 10 views
5

मैं एआरएम माइक्रोकंट्रोलर (एसएएम 7) के लिए एम्बेडेड सॉफ़्टवेयर पर काम कर रहा हूं और यागार्टो टूलचैन का उपयोग कर रहा हूं।मैं नए एलआईबीसी लागू कार्यों के कस्टम कार्यान्वयन का उपयोग करने के लिए जीसीसी को कैसे मजबूर कर सकता हूं?

मेरा कोड वर्तमान में libc.a से लिंक करता है। हालांकि मैं बिल्टिन फ़ंक्शन memcpy का एक कस्टम कार्यान्वयन का उपयोग करना चाहता हूं जो मेरे कोड में पहले से है।

मैं GCC Manual में निर्दिष्ट लेकिन लिंकर अभी भी शिकायत निम्नलिखित होगा चेतावनी के रूप में -fno-निर्मित और/या -fno-निर्मित-memcpy उपयोग करने की कोशिश की है:

contiki-crazy-horse.a(flashd_efc.o): In function `memcpy': 
C:\Users\Melvin\GitRepo\projects\Amatis_Project\SAM7_Contiki\examples\er-rest-example/../../cpu/arm//at91sam7s-x/./flashd_efc.c:669: multiple definition of `memcpy' 
c:/toolchains/yagarto/bin/../lib/gcc/arm-none-eabi/4.6.2/../../../../arm-none-eabi/lib\libc.a(lib_a-memcpy.o):C:\msys\1.0\home\yagarto\newlib-build\arm-none-eabi\newlib\libc\string/../../../../../newlib-1.19.0/newlib/libc/string/memcpy.c:78: first defined here 
collect2: ld returned 1 exit status 
make: *** [rest-server-example-nosyms.crazy-horse] Error 1 
../../cpu/arm/at91sam7s-x/Makefile.at91sam7s-x:181: recipe for target `rest-server-example-nosyms.crazy-horse' failed 

क्या सही तरीका है कुछ जीसीसी अंतर्निहित कार्यों के कस्टम कार्यान्वयन का उपयोग करने के लिए?

संपादित करें 1: लिंकिंग कमांड जोड़ रहा हूं जिसका मैं उपयोग कर रहा हूं। नीचे दिए गए कोड में Porject.a एक प्रोजेक्ट फ़ाइल है जो सभी प्रोजेक्ट की ऑब्जेक्ट फ़ाइलों के साथ बनाई गई है।

CC  = arm-none-eabi-gcc 
CFLAGSNO = -I. -I$(CONTIKI)/core -I$(CONTIKI_CPU) -I$(CONTIKI_CPU)/loader \ 
     -I$(CONTIKI_CPU)/dbg-io \ 
      -I$(CONTIKI)/platform/$(TARGET) \ 
      ${addprefix -I,$(APPDIRS)} \ 
      -DWITH_UIP -DWITH_ASCII -DMCK=$(MCK) \ 
      -Wall $(ARCH_FLAGS) -g -D SUBTARGET=$(SUBTARGET) 

CFLAGS += $(CFLAGSNO) -O -DRUN_AS_SYSTEM -DROM_RUN -ffunction-sections 

LDFLAGS += -L $(CONTIKI_CPU) --verbose -T $(LINKERSCRIPT) -nostartfiles -Wl,-Map,$(TARGET).map 

$(CC) $(LDFLAGS) $(CFLAGS) -nostartfiles -o project.elf -lc Project.a 
+0

लिंकर कमांड लाइन भी शामिल करें जो इस त्रुटि को उत्पन्न करता है। – Clifford

+0

@ क्लाइफोर्ड I ने आपके द्वारा अनुरोधित जानकारी को जोड़ने के लिए मूल पोस्ट संपादित किया – maguirre

उत्तर

3

यह libc.a में memcpy() रही है, तो यह किसी भी "निर्मित" के साथ परस्पर विरोधी नहीं है, बल्कि newlib कार्यान्वयन के साथ। आपको -nostdlibs विकल्प निर्दिष्ट करने और आवश्यकतानुसार libc.a और libm.a को स्पष्ट रूप से लिंक करने की आवश्यकता हो सकती है।

ऑब्जेक्ट (.o) फ़ाइलें लाइब्रेरी अभिलेखागार (.a) फ़ाइलों की खोज से पहले जुड़ी हुई हैं, इसलिए अगर किसी ऑब्जेक्ट फ़ाइल द्वारा प्रतीक का समाधान किया जाता है, तो इसे अभिलेखागार में खोजा नहीं जाएगा। यदि आप अपने ओवरराइड को स्थिर-लिंक लाइब्रेरी में रखते हैं, तो आप लिंकर कमांड लाइन पर मानक लाइब्रेरी (या मानक लाइब्रेरी का उपयोग करने वाली किसी अन्य लाइब्रेरी) से पहले इसे सूचीबद्ध करते हैं।

[जोड़ा गया]निम्नलिखित मूल रूप से एक "टिप्पणी" लेकिन शायद जवाब में होना चाहिए; यह प्रश्न में "संपादन 1" के जवाब में है, और लिंक आदेश के बारे में नीचे दी गई टिप्पणी:

-nostartfiles -o project.elf -lc Project.a से -nostdlib -o project.elf -start-group Project.a -lc -end-group बदलें। स्विच -nostdlib दोनों स्टार्ट-अप फ़ाइलों (यानी -nostartfiles) और मानक लाइब्रेरीज़ के डिफ़ॉल्ट लिंकिंग को अक्षम करता है। लाइब्रेरी ग्रुपिंग समूह में लाइब्रेरी को तब तक खोजा जा सकता है जब तक कोई और प्रतीकों का समाधान नहीं किया जा सके, जिससे ऑर्डर-ऑर्डर और सर्कुलर निर्भरता आपके जैसे हल हो जाएं। समूह स्विच के लिए एक वैकल्पिक रूप -(Project.a -lc -) है।

+0

@Cliford। मेरी गलती। आप सही हैं क्या यह चुनने का कोई तरीका है कि memcpy का कौन सा कार्यान्वयन मैं अपने कोड को लिंक करना चाहता हूं? मैं क्योंकि मेरी परियोजना कुछ ठूंठ कार्यों कि libc.a जरूरत – maguirre

+2

@Mischief है Project.a और libc.a के बीच जोड़ने के क्रम परिवर्तन नहीं कर सकते: वैकल्पिक रूप से, अपनी परियोजना फाइलों 'Project.a -lc स्टब्स से अपने newlib स्टब्स अलग .a'। अपनी प्रोजेक्ट फ़ाइलों के लिए एक संग्रह का उपयोग करना एक असामान्य बात है; आप सामान्य रूप से ऑब्जेक्ट फ़ाइलों को सीधे लिंक करके समस्या से बच सकते हैं। ऑब्जेक्ट फ़ाइलों में कोड हमेशा लिंक ऑर्डर के बावजूद लाइब्रेरी कोड की प्राथमिकता में उपयोग किया जाएगा; इसलिए libc स्टब्स को किसी भी ऑब्जेक्ट कोड द्वारा हल किया जाएगा जो आप मेल खाने वाले प्रतीकों से लिंक करते हैं, और लाइब्रेरी कोड से पहले किसी ऑब्जेक्ट कोड को अन्य ऑब्जेक्ट कोड से हल किया जाएगा, इसलिए memcpy() libc के भीतर कॉल के लिए भी सही ढंग से ओवरराइड किया जाएगा। – Clifford

+0

मैं संग्रह में कोड रखने के बारे में आपकी टिप्पणी पर आपसे सहमत हूं असामान्य है। अगर/जब मेरे पास रास्ता है तो यह बदल जाएगा – maguirre

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

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