Hallo, zur Zeit bin ich dabei eine Entwicklungsumgebung für ein Projekt mit dem TMS470 von Texas Instrument aufzusetzen. Als IDE benutze ich dafür Eclipse. Nun zu meinem aktuellen Problem: Ich möchte nun die C++-Unterstützung in das Projekt aufnehmen und habe dazu das Makefile (siehe Dateianhang) entsprechend erweitert. Erzeuge ich nun ein Klassenobjekt im globalen Namensraum funktioniert es scheinbar auch problemlos. Sobald ich jedoch das Klassenobjekt innerhalb z.B. der main-Funktion erzeugen will, gibt es einen Linkerfehler: tms470r1b1m_flashlight.o: In function `main':F:\TMS470\src\FlashLight_Demo/tms470r1b1m_flashlight.cpp:95: undefined reference to `__gxx_personality_sj0' Daraufhin habe ich nach der fehlenden Referenz im WinARM-Verzeichnis gesucht und habe diese unteranderem in der Library libstd++.a gefunden. Jedoch hat ein hinzufügen der Linkeranweisung -lstd++ und damit das Einbinden der Library zu keinem Erfolg geführt. Hat irgendjemand eine Idee was hier evtl. noch fehlt? Karsten
Durch dein geniales Makefile blicke ich leider nicht durch. Schicke mal die Ausgabe von "make" für die Kommandozeile, die zum Linken benutzt wird (also was genau "make" dabei aufruft).
Hallo Jörg, meinst Du die Ausgabe mit --just-print? Ich habe sie als Dateianhang eingefügt. Karsten
> meinst Du die Ausgabe mit --just-print? Mir hätte cut&paste der Kommandozeile genügt, die "make" ausgibt, wenn man einfach nur "make" startet. Anyway, das tut's auch. > echo Linker-Vorgang läuft... > arm-elf-gcc -nostartfiles -oFlashLight_Demo.elf ... Das sollte arm-elf-g++ sein, nicht arm-elf-gcc. Wenn du das Linkerkommando schon unbedingt selbst bauen willst, dann lass den C++-Compiler einmal mit -v laufen und sieh' dir an, was für einen Aufruf für arm-elf-ld er zusammennagelt, danach customize dir diesen nach deinem Bedarf. Meine ganz persönliche Meinung: ich würde das Linken dem Compiler komplett überlassen, soweit möglich, und versuchen, den Linker mit -Wl-Optionen über den Compiler zu tunen, wo nötig. Aber ich habe vom ARM selbst keine Ahnung, irgendwas wirst du dir ja bei dieser recht umständlichen Variante auch gedacht haben.
Hallo Jörg, erst einmal noch einmal vielen Dank für deine Antwort. Ich habe jetzt c++ für das Linken verwendet und unter anderem fehlende Referenzen auf syscalls wie folgt: c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(ma llocr.o): In function `_malloc_r':mallocr.c:(.text+0x430): undefined reference to `_sbrk_r' :mallocr.c:(.text+0x5ec): undefined reference to `_sbrk_r' c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(fr eer.o): In function `_malloc_trim_r':mallocr.c:(.text+0x48): undefined reference to `_sbrk_r' :mallocr.c:(.text+0x70): undefined reference to `_sbrk_r' :mallocr.c:(.text+0xb4): undefined reference to `_sbrk_r' c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(ma kebuf.o): In function `__smakebuf':makebuf.c:(.text+0x44): undefined reference to `_fstat_r' :makebuf.c:(.text+0xe4): undefined reference to `isatty' c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(st dio.o): In function `__sread':stdio.c:(.text+0x1c): undefined reference to `_read_r' c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(st dio.o): In function `__swrite':stdio.c:(.text+0x78): undefined reference to `_lseek_r' :stdio.c:(.text+0x9c): undefined reference to `_write_r' c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(st dio.o): In function `__sseek':stdio.c:(.text+0xc0): undefined reference to `_lseek_r' c:/winarm/bin/../lib/gcc/arm-elf/4.0.2/../../../../arm-elf/lib\libc.a(st dio.o): In function `__sclose':stdio.c:(.text+0xf8): undefined reference to `_close_r' Soweit ich das im Moment überblicke, hängen die mit der newlib Library zusammen. Vielen Dank für den Tip mit der Option -v. Hätte ich auch allein drauf kommen können. In der Ausgabe des Compilers habe ich dann folgende Diskrepanzen entdeckt: 1. Vor dem Aufruf des as, cc1 und ld wird configure (unter anderem mit der Option --with-newlib) aufgerufen. --> Dies erklärt auch die unreferenzierten syscalls. Ich will newlib aber nicht einbinden! Wie kann ich das verhindern bzw. warum wird überhaupt configure aufgerufen? 2. Der Linker bindet zusätzlich zu meinem Startup-Code crt0.S ein Startup-Code-Modul ebenfalls crt0.S aber aus dem WinARM/lib-Verzeichnis ein. Dies führt durch Zufall zu doppelt definierten Symbolen wzb. _start. Und jetzt bin ich komplett raus. Wieso wird der Startup-Code aus dem WinARM-Verzeichnis geladen? Karsten
Hallo, ich bin's noch mal. Als Nachtrag zur vollkommenen Verwirrung: In der Ausgabe des Compilers ist folgende Zeile zu finden: Configured with: ../../gcc-4.0.2/configure --enable-languages=c,c++ --enable-interwork --enable-multilib --with-gcc --with-gnu-ld --with-gnu-as --with-stabs --disable-shared --disable-threads --disable-win32-registry --disable-nls --target=arm-elf --with-newlib --prefix=c:/WinARM -v Ich kann aber im gesamten WinARM-Verzeichnis kein configure finden. Was wird hier dann ausgeführt? Die Ausgabe deutet eindeutig auf ein Filesystem hin. Karsten
Nur der Vollständigkeit halber habe ich noch die kompletten Compiler-Ausgabe beigefügt. Siehe Dateianhang. Ich hoffe jemand kennt ein ähnliches Problem und kann mir hier weiterhelfen. Karsten
Wenn du die Zeilen mal nicht umbrichst, dann würdest du feststellen, dass der Satz anfängt mit "configured with". D. h. natürlich wird jetzt und gerade kein configure bei dir aufgerufen, sondern das passierte, bevor der Compiler gebaut worden ist. > Soweit ich das im Moment überblicke, hängen die mit der > newlib Library zusammen. Kann sein. Ein Teil der C++-Bibliothek wird zwangsläufig Rückgriffe auf die Standardbibliothek brauche, bspw. auf malloc() und free() (für new und delete). Du wirst also wohl oder übel entweder selbst ein malloc/free liefern müssen oder aber die newlib zum Laufen bekommen. Hier verließen sie ihn aber: ich kenne mich mit ARM und newlib nicht aus. Die Frage nach dem sbrk() kam aber vor paar Tagen schon einmal. > Der Linker bindet zusätzlich zu meinem Startup-Code crt0.S ein > Startup-Code-Modul ebenfalls crt0.S aber aus dem > WinARM/lib-Verzeichnis ein. Das würde ich für normal halten. Warum willst du denn partout den Startup-Code selbst zimmern, wenn es einen fertigen gibt? Wenn du es aber selbst machen willst, dann ist das eben genau der Teil, den du in deinem Projekt ersetzen musst. Mein Tipp war ja, die originale Linker-Kommandozeile als Vorlage zu benutzen, um dann die eigenen Änderungen/Ergänzungen vorzunehmen. Für normal würde ich es aber ansehen, dass man den ganzen Zirkus eigentlich nicht braucht, sondern mit dem arbeitet, was einem die Hersteller der Tools mit auf den Weg gegeben haben.
Hallo Jörg, vielen Dank für deine Ausdauer. ;) Ok, das mit dem configure habe ich nicht gewusst und die Geschichte mit der newlib werde ich mir noch einmal anschauen. Aber nun zum Startup-Code. Wenn Du Dir einmal die Beispiel-Projekte aus dem WinArm-Projekt anschaust, wirst Du sehen, dass man scheinbar für jeden Microcontroller einen speziellen Startup-Code benötigt. Oder ist dies etwa auch Blödsinn? Karsten
Hallo Jörg, die Sache mit dem Startup-Code ist nun geklärt. Die Linker-Option -nostartfiles unterdrückt das Einbinden des WinARM-Codes. Es bleibt also nur noch die Sache mit der newlib offen. Karsten
> Wenn Du Dir einmal die Beispiel-Projekte aus dem WinArm-Projekt > anschaust, wirst Du sehen, dass man scheinbar für jeden > Microcontroller einen speziellen Startup-Code benötigt. Das ist natürlich schade. Ich hätte von der Portierung erwartet, dass sie diese Abhängigkeit selbst auflöst. So geschieht es jedenfalls beim AVR-GCC. > Es bleibt also nur noch die Sache mit der newlib offen. Suche mal das Forum danach. Gerade das Thema sbrk war hier erst vor kurzem diskutiert worden.
Hallo Jörg, die Suche nach _sbrk_r im Forum hat leider nicht funktioniert. Ich habe nicht einmal unsere Einträge gefunden. ??? Bin ich zu blöd? Kannst Du dich evtl. noch an den Thread-Titel erinnern? Wohl weniger, oder? Karsten
Hallo Jörg, vielen Dank für deine Hilfe. Ab diesem Punkt werde ich versuchen das Problem mit der newlib erst einmal selbstständig zu lösen. So wie es aussieht steht mir hier ein Portieren auf den TMS470 bevor. Also wie gesagt, noch einmal vielen Dank für Deine Hilfe und Ausdauer. Karsten
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.