Hi Leute, mein Compiler bzw. der Linker bereitet mir gerade ein paar Kopfschmerzen. Versuche gerade einfach folgenden Code zu übersetzen: ----------------------------------------------------------- #include <cfg/crt.h> /* Floating point configuration. */ #include <string.h> #include <stdio.h> #include <io.h> #include <dev/board.h> #include <sys/timer.h> int main(int argc, char ** argv) { return(0); } ----------------------------------------------------------- Leider bekomme ich dabei folgende Meldung: ----------------------------------------------------------- Compiling: main.c avr-gcc -c -mmcu=atmega128 -I. -gstabs -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=main.lst -I/home/schmeissfliege/ethernut-4.2.1/include/ -std=gnu99 -DF_OSC=3686400 -MD -MP -MF .dep/main.o.d main.c -o main.o Linking: main.elf avr-gcc main.o --output main.elf -Wl,-Map=main.map,--cref -lm /usr/lib/gcc/avr/3.4.3/../../../../avr/lib/crts8515.o(.init9+0x0): In function `__bad_interrupt': ../../crt1/gcrt1.S:104: undefined reference to `main' make: *** [main.elf] Fehler 1 ----------------------------------------------------------- Meiner Meinung nach versucht er in einem .o-file eine main zu finden, also habe ich irgendwo ein falsches Flag gesetzt. Der verantwortliche Teile in der make-file sieht so aus: ----------------------------------------------------------- # Link: create ELF output file from object files. .SECONDARY : $(TARGET).elf .PRECIOUS : $(OBJ) %.elf: $(OBJ) @echo @echo $(MSG_LINKING) $@ $(CC) $(AL_CFLAGS) $(OBJ) --output $@ $(LDFLAGS) ----------------------------------------------------------- Habe gehofft, dass die Option -o mir weiterhelfen würde,doch leider ohne Erfolg. Falls die makefile-Ausschnitt doch nicht für den Fehler verantwortlich sein sollt, hab ich das das komplette makefile angehängt. Sieht von euch jemand meinen Fehler?? Danke Gregor
> ... avr-gcc -c -mmcu=atmega128 aber > ... crts8515.o Du solltest dir darüber einig werde, ob du für einen ATmega128 oder einen AT90S8515 compilieren und linken willst. Ansonsten sehe ich keinen offensichtlichen Fehler, wobei es mich schon stutzig macht, dass du ein #include <io.h> so ohne weiteres aufgelöst bekommst... Ich frage mich da gerade, was für eine io.h das ist (eine von Ethernut?), jedenfalls wohl nicht die <avr/io.h> aus der avr-libc.
Hi Jörg, ist ansich alles für nen ATmega128. Die io.h ist von ethernut und die includes habe ich auch erstmal zum testen aus nem Beispielprojekt von denen übernommen. Das mit dem AT90S8515 ist ja doof, hab keine Ahnung wo das her kommt?!? Hab gerade herausgefunden, dass wenn nur: #include <cfg/crt.h> /* Floating point configuration. */ #include <string.h> gesetzt ist, alles ohne Probleme gelinkt wird. Sobald allerdings eine der anderen includes mit in den Code genommen wird, klappt es wieder nicht und obiges Problem tritt auf. Gibt es Unterschiede zwischen z.B. der stdio.h von avr und der von ethernut?? Werd mal ein bisschen recherchieren, wenn jmd. noch ne Idee hat, kann er Sie ja mal äußern.
> Das mit dem AT90S8515 ist ja doof, hab keine Ahnung wo das her kommt?!? Vom vergessenen -mmcu=atmega128 beim Linken. > Die io.h ist von ethernut ... Hmm, naja, falls das ein Ersatz für <avr/io.h> sein soll: schulterzuck. > Gibt es Unterschiede zwischen z.B. der stdio.h von avr und der von > ethernut? Vermutlich. Beide dürften sehr unabhängig voneinander geschrieben worden sein. Ich find's 'ne doofe Idee von Ethernut, C-Standard-Headerdateien mit eigenen Inhalten erfinden zu wollen. Das muss früher oder später schief gehen, da der C-Standard das verbietet. Vielleicht lässt sich der Kram ja mit -ffreestanding noch compilieren und linken, aber dann vermasselst du dir eine ganze Reihe an möglichen Optimierungen.
>>Vom vergessenen -mmcu=atmega128 beim Linken. Meinst du damit, dass ich das vergessen habe bzw. es in der Makefile fehlt? >>Vielleicht lässt sich der Kram ja mit -ffreestanding noch compilieren und linken. Funktioniert leider auch nicht. Hab mir die stdio.h von avr und ethernut mal angeschaut und es scheint, als ob sie doch denselben Inhalt hätten. Naja, mal abwarten und Foren durchstöbern. Aber vielleicht hat ja noch jemand hier ne Idee wodrann es liegen könnte.
Georg wrote: >>>Vom vergessenen -mmcu=atmega128 beim Linken. > Meinst du damit, dass ich das vergessen habe bzw. es in der Makefile > fehlt? Ja. Was sagt denn avr-nm main.o?
avr-nm main.o sagt mir: U __do_clear_bss U __do_copy_data 00000006 t Letext 00000000 T NutAppMain 0000003e a _SP_H_ 0000003d a _SP_L_ 0000003f a _SREG_ 00000000 a _tmp_reg_ 00000001 a _zero_reg_ Muss aber gestehen, dass ich mit diesem Ergebnis nichts anfangen kann. Hoffe, dass du mir wenn was nicht stimmen sollte es mir interpretieren kannst. Habe mal -mmcu=atmega128 in den Linker-Optionen für die .elf-file hinzugefügt leider ohne Erfolg.
Georg wrote: > U __do_clear_bss > U __do_copy_data > 00000006 t Letext > 00000000 T NutAppMain > 0000003e a __SP_H__ > 0000003d a __SP_L__ > 0000003f a __SREG__ > 00000000 a __tmp_reg__ > 00000001 a __zero_reg__ > Muss aber gestehen, dass ich mit diesem Ergebnis nichts anfangen kann. > Hoffe, dass du mir wenn was nicht stimmen sollte es mir interpretieren > kannst. Kein main() drin zu sehen, nur ein NutAppMain(). Offenbar definiert NutOS main in einem Makro um. Dann musst du aber irgendwie auch die Bibliotheken von NutOS mit linken, weil sie dort offenbar ja ihr eigenes main() haben werden. Wie heißt es so schön: ``If all else fails, read the documentation.'' In diesem Falle die zu Ethernut/NutOS.
>>Dann musst du aber irgendwie auch die Bibliotheken von NutOS mit linken...
Die habe ich mitgelinkt. Dürfte glaub ich auch die einzigen sein, die
gelinkt werden oder schaut avr-gcc automatisch in seinem
include-Verzeichnis nach, was er davon benutzen kann?
Fall ja, habe ich irgendwie die Möglichkeit das zu unterbinden??
Aber werd jetzt mal erneut die Nut/OS-Doku durchackern, vielleicht hab
ich ja was übersehen...
Georg wrote: >>>Dann musst du aber irgendwie auch die Bibliotheken von NutOS mit linken... > Die habe ich mitgelinkt. Wo denn? Ich sehe da nur ein -lm, die Gleitkomma-Bibliothek. > Dürfte glaub ich auch die einzigen sein, die > gelinkt werden oder schaut avr-gcc automatisch in seinem > include-Verzeichnis nach, was er davon benutzen kann? Das hat nichts mit include zu tun, ich sprach vom Linker, nicht vom Compiler.
Die Main Auflösung ? http://www.sigterm.de/projects/emusimfire/html/node9.html#SECTION05211100000000000000 zeeju
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.