ARM-elf-gcc, undefined reference, probleme in Makefile

[Jochen V. (jochen-v)]

Hallo alle zusammen,

seit geraumer Zeit befasse ich mich mit dem Thema ARM7. Dazu hab ich ein 
Olimex EX-256 Evaluation Board. Mein Problem habe ich versucht über die 
Suche zu lösen, hab zwar einiges zum Thema gefunden aber nichts das mich 
weiter gebracht hat.

Als Entwicklungsumgebung verwende ich Eclipse/Yagarto.
Nun habe ich vor im Rahmen einer Projektarbeit an der Hochschule den 
SD-Kartenleser in Betrieb zu nehmen, hierfür möchte ich ELM CHAN's File 
System Modul verwenden. Begonnen habe ich damit eine USART Kommunikation 
zu starten für Debuggingzwecke, das hat auch alles wunderbar 
funktioniert. So kurz nebenbei als "Vorlage" hierzu habe ich James 
Lynch's tutorial über Serial Communication verwendet.

Jetzt zum problem:
Wenn ich Das File System Module integriere bekomme ich beim linken 
folgende Fehlermeldungen:
>>>>undefined reference to `memcmp'
>>>>undefined reference to `memset'
>>>>undefined reference to `strcpy'
>>>>undefined reference to `strlen'

memcmp ist ja eine funktion aus der Bibliothek String.h, diese habe ich 
aber über include eingebunden. Meine Vermutung ist jetzt das ich im 
Makefile irgendeinen Fehler habe, hier mal ein Ausschnitt:

># variables
>CC  = arm-elf-gcc
>AS  = arm-elf-as
>LD  = arm-elf-ld -v -lc
>CP  = arm-elf-objcopy
>OD  = arm-elf-objdump

>CFLAGS  = -mcpu=arm7tdmi -I./ -c -fno-common -O0 -g -fomit-frame-pointer 
>-Wcast-align
>ASFLAGS  = -mapcs-32 -g
>LFLAGS  =  -omain.out -Tdemo_sam7ex256.cmd -Map main.map --cref
>CPFLAGS = --output-target=binary
>ODFLAGS  = -x --syms

># list of dependencies for each C and ASM file in the project
># Note:  Implicit Rules will deduce from the source file extension
> which to run: C compiler or ARM assembler
>crt.o:              crt.s
>main.o:             main.c
>lowlevelinit.o:     lowlevelinit.c
>usart0.o:         usart0.c
>mmc.o:            mmc.c
>usart0_isr.o:    usart0_isr.c
>ff.o:           ff.c
>isrsupport.o:       isrsupport.c

Mit Makefiles kenne ich mich bis jetzt nich so sonderlich gut aus, habe 
dazu einfach die Makefile von James L. erweitert, damit bin ich bis 
jetzt auch ganz gut gefahren. Biblitheken wie string.h hatte ich bisher 
aber auch nicht eingebunden.
Eine frage mal dazu noch am Rande, James L. hatte in seiner "list of 
dependencies" hinter den C-files immernoch die zugehörigen header files 
angegeben, sind die wirklich nötig? Hab die mal versuchsweise entfernt 
und bin immer zum gleichen ergebniss gekommen, dachte auch das so 
verstanden zu haben das die nicht in der Makefile angegeben werden 
müssen.


Wäre super wenn sich dieses Problem jemand anschauen könnte und evtl 
eine Idee hätte woran das liegen könnte bzw. was ich falsch mache.



Gruß & Danke
Jochen

[Oliver (Gast)]

>memcmp ist ja eine funktion aus der Bibliothek String.h

Nein. String.h ist keine Bibliothek, sondern nur eine Headerdatei mit 
den Funktionsprototypen. Die Funktionen selber stecken in den 
eigentlichen libraries, die du dazulinken musst. Insofern suchst du im 
makefile an der falschen Stelle.

Oliver

[let (Gast)]

Anscheinend verwendest du direkt den ld zum Linken. Ich würde
den gcc dazu nehmen.

Aber vielleicht genügt es ja schon wenn du

LD  = arm-elf-ld -v -lc

durch

LD  = arm-elf-ld -v -lc -lgcc

ersetzt.

[Jochen V. (jochen-v)]

Hallo,

dankeschonmal für die Anregungen, bin leider erst jetzt wieder dazu 
gekommen das auszuprobieren.

Wenn ich so wie von let vorgeschlagen versuche die libgcc.a über

> LD  = arm-elf-ld -v -lc -lgcc

in der Makefile versuche dazuzulinken geht das mit folgender 
Fehlermeldung schief:

> arm-elf-ld: cannot find -lgcc


Die Libgcc.a befindet sich im Projektverzeichnis, irgendeine Pfadangabe 
fehlt dem Linker wohl aber doch.

Habe dann beim Linkeraufruf die Libgcc.a mitdrangehängt, dann kommt zwar 
keine Fehlermeldung das er sie nicht findet, aber das ursprüngliche 
Problem löst das nicht, dadurch ändert sich nichts. Der Aufruf sieht so 
aus:

> $(LD) -o main.out $(OBJECTS) $(LFLAGS) libgcc.a


Ich werde mich jetzt mal dran machen und eine Makefile basteln die so 
wie von let vorgeschlagen nicht den ld direkt zum linken verwendet 
sondern über den GCC geht.
Falls aber trotzdem jemand eine Idee hat woran das liegen könnte wär ich 
sehr dankbar, hab meine Makefile mal in den Anhang gesetzt.


Grüße Jochen

[Tilo (Gast)]

Die Frage ist vielleicht ein wenig blöd nur wozu überhaupt ein Makefile?
Ich verwende das gnuarm Eclsipe Plugin und kümmere mich seit dem gar 
nicht mehr um Makefiles.

[Jochen V. (jochen-v)]

Hm find die frage kein bisschen blöd, werd das mal ausprobieren, hatte 
bisher nur einen Makefile generator ausprobiert, der im stile von mfile 
aufgebaut war, der führte mich aber leider nicht zum Ergebniss....

Werde das Plugin mal testen, Dankeschön schonmal.

Gruß

[Martin Thomas (Gast)]

Über das Frontend (arm-*-gcc) den Linker indirekt aufzurufen, wie 
bereits vorgeschlagen, dürfte das Problem mit der nicht-gefundenen 
libgcc beheben. Der Linker selbst weiss nicht von sich aus, wo er 
dannach suchen soll, ein Aufruf über *-gcc gibt aber die entsprechenden 
Suchpfade "intern" mit.
Warum eine libgcc.a im Projektverzeichnis? Das dürfte spätestens dann zu 
Verdruss führen, wenn jemand anderes das Projekt zusammenbauen will aber 
andere Versionen von Compiler und/oder Binutils benutzt.

[Jochen V. (jochen-v)]

Sodele, wollt mal kurz bescheid geben mit dem indirekten Aufruf des 
Linkers das hat jetzt funktioniert, danke an euch für die Hilfe.

Gruß Jochen