F
@Timo_R sagte in Kompilierfehler, Ideen?:
@Finnegan
Dank für Ihre Antwort.
Wir nutzen die arm-none-eabi eigentlich als ungesehenes Kompilierwerkzeug.
"Ungesehen" heißt hier es arbeitet im Hintergrund einer IDE oder sowas?
Mich interessiert hier vor allem folgendes:
Wo stammt der Compiler her? Ist der Teil eines SDK? Gibt es dazu eine Dokumentation und vielleicht sogar einen Support, der wahrscheinlich zielgerichteter helfen könnte als wir hier?
Mehrere Fragen tun sich natürlich hier auch auf, ich arbeite derzeit auf einem 32-bit Intel Atom und benötige - wie es bis dato scheint - dennoch dieses Werkzeug zum Kompilieren um ein Programm einem Cortex-M4 zur Verfügung zu stellen.
Das ist sehr unspezifisch formuliert ... was ist das denn für ein Maschinchen, in dem der Cortex-M4 steckt? Ein "Computer" ist ja nicht nur die CPU, sondern auch die ganze Hardware drumherum, und eine libc-Unterstützung ohne OS muss eben gerade diese Hardware kennen und korrekt ansprechen. Ein printf muss z.B. wissen, wie man Text auf dem "Terminal" ausgibt. Das kann z.B. über eine BIOS/Firmware-Funktion geschehen, oder man schreibt die Zeichen irgendwo in einen in den Adressraum gemappten Text-Videospeicher. Oder man muss den Text über den seriellen Port oder irgendeine andere Hardware ausgeben. Das kann in allen Fällen ein Cortex-M4 sein, aber wie die Grundfunktionen der libc implementiert sein müssen, ist primär davon abhängig, wie und mit welchen Chips die CPU zu einem "Computer" verlötet wurde
Jedoch:
Ihr zweiter Absatz ist interessant - newlib-basierte libc Linkung und das linken über die Kommandozeile, wie mache ich das? Das ist es eigentlich m. E. "schon"...
Kurze prägnante Quellen würden reichen.
newlib an sich ist keine fertige Lösung, sondern eine libc-Implementierung, die sich relativ leicht auf neue (oft selbst entwickelte, "embedded") Systeme portieren lässt, indem man lediglich ein paar lowlevel-Grundfunktionen für das System implementiert. Sowas selbst zu machen erfordert detailliertes Wissen über die Ziel-Hardware und über die Funktionsweise von Compiler und Linker. Davon würde ich vorerst abraten, besonders wenn Compiler und Linker über die Kommandozeile zu bedienen noch neu für dich ist. Neben Kenntnissen über die Hardware sollte man mindestens in der Lage sein, sich eine GCC-Toolchain mit libc selbst zu bauen, bevor man damit anfängt.
Aber du arbeitest ja offenbar schon mit einer newlib-basierten libc, so wie die Pfade in deiner zweiten Fehlermeldung aussehen: ../newlib/libc/stdlib/exit.c. Wo stammt die denn her? Ich denke die ist einfach nur falsch konfiguriert oder nicht richtig eingebunden.
Wir benutzen die arm-none-eabi also obwohl "Kreuz-Kompilierer" auf einem 32 bit System, weil wir nicht soviel Ahnung genau vom kompilieren haben.
In diesem Fall für eine U(S)ART-Schnittstelle.
Wie gesagt. Sehr unspezifisch. Das System, auf dem der Compiler läuft, ist hier auch m.E. nicht das Problem.
Bitte um mehr Infos woher der Compiler kommt (die Toolchain muss ja irgendjemand für eure Ziel-Hardware zusammengestellt haben) und was das für ein System ist, auf dem die damit gebauten Programme laufen sollen.
