Hallo zusammen,
Aufgrund längerer Abstinenz zu jeglichem Mikrocontroller gebastel bin
ich leider ein wenig eingerostet ;-)
Könnte mir evtl. jemand kurz auf die Sprünge helfen, was ich Einstellen
oder per environment variable konfigurieren sollte, damit der Linker die
libs und startup-files findet?
Mein Compile-output zeigt derzeit:
1
/usr/lib64/gcc/arm-none-eabi/8/ld: cannot find crti.o: No such file or directory
2
/usr/lib64/gcc/arm-none-eabi/8/ld: cannot find crtbegin.o: No such file or directory
Das sollte nicht passieren. Welche Compiler-Distribution ist
installiert? Bei GCC-ARM-Embedded ist das alles vorkonfiguriert und
funktioniert:
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
Die bei Linux-Distributionen mitgelieferten GCC-Pakete sind leider oft
veraltet und/oder unvollständig.
Ich nutze neuerdings openSuSE Tumbleweed (wegen der rolling releases und
einem sehr aktuellen gnuradio, im Vergleich zu anderen Distributionen).
Die aktuelle Toolchain heisst da "cross-arm-none-*", siehe:
Patrick D. schrieb:> Es ist also nicht empfehlenswert, diese zu nutzen?
Bei Suse weiß ich das nicht. Bei Ubuntu/Debian ist/war das jedenfalls
problematisch.
Patrick D. schrieb:> Gibt es "best practices" um ein brauchbares build-system zu bekommen?https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
Rechts auf Download klicken, Datei entpacken, "PATH" Variable anpassen,
fertig. Ist dann auch konsistent zu dem was die meisten hier verwenden
und was diverse IDEs mitliefern.
Patrick D. schrieb:> Ich nutze neuerdings openSuSE Tumbleweed (wegen der rolling releases und> einem sehr aktuellen gnuradio, im Vergleich zu anderen Distributionen).
Du hast gcc7 und gcc8 parallel installiert. An sich sollte das
funktionieren, aber gelegentlich kommt da was durcheinander, so
vielleicht auch bei Dir.
Deinstalliere mal alle cross-arm-none-* Pakete und installiere dann nur
cross-arm-none-gcc8 cross-arm-none-newlib-devel und deren
Abhängigkeiten. Damit konnte ich gerade Black Magic Probe und OpenDPS
problemlos compilieren.
Falls Dir das auch nicht hilft, nimm mal statt der Tumbleweed-Pakete die
Pakete für Leap 15 aus diesem Repository:
https://download.opensuse.org/repositories/home:/duwe:/crosstools2/openSUSE_Leap_15.0/
cross-arm-none-eabi-gcc
cross-arm-none-eabi-newlib
cross-arm-none-eabi-binutils
Niklas G. schrieb:> Bei GCC-ARM-Embedded ist das alles vorkonfiguriert und> funktioniert:>> https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
und auch das noch:
> Ist dann auch konsistent zu dem was die meisten hier verwenden> und was diverse IDEs mitliefern.
und:
Patrick D. schrieb:> Ich habe jetzt die Toolchain installiert, die Niklas empfohlen hat.> Einfacher geht es fast nicht.
und direkt von der Quelle, ein Traum, das wäre ja perfekt für jeden...
Aber hast du evt. auch einen Tipp, wo man ein ähnliches Paket für
32-Bit Linux bekommt?
> Die bei Linux-Distributionen mitgelieferten GCC-Pakete sind leider oft> veraltet und/oder unvollständig.
Bei Debian kann ich "veraltet" unterschreiben. Aber unvollständig nun
wirklich nicht. Ich hab's installiert wie jedes andere Debian-Paket und
alles funktioniert sofort, ohne jede Handarbeit.
Bauform B. schrieb:> Aber hast du evt. auch einen Tipp, wo man ein ähnliches Paket für 32-Bit> Linux bekommt?
Wer benutzt denn noch 32bit Rechner... Man kann das Source Paket
herunter laden und selbst kompilieren.
Nico W. schrieb:> Für 32bit gibt es den 5er bei ARM.
Naja, seit dem hat sich doch einiges getan...
> Ggf. kannst ja das bleeding edge script[1] nutzen.>> [1] https://github.com/FreddieChopin/bleeding-edge-toolchain
Das benutze ich, z.Zt. mit gcc-7.1. Es funktioniert, bis auf
Kleinigkeiten. Zum Beispiel müssen Programme für den Cortex-M0 ohne
Divisionen auskommen (undefined reference to `__aeabi_idiv' u.ä.). Und
ich wage es nicht (mehr), lto einzuschalten. Sowas passiert mit dem
fertigen Paket wahrscheinlich nicht.
Harry L. schrieb:> Damit kann man sich unter Linux sehr einfach jede gewünschte> GCC-Toolchain bauen:>> https://crosstool-ng.github.io/
Das scheint mir das gleiche zu sein, nur hübscher verpackt. Ob ich damit
besser klar komme?
Jedenfalls danke für die Tipps.
Niklas Gürtler schrieb:> Wer benutzt denn noch 32bit Rechner...
Jemand, der Angst vor neuen, heimtückischen Fehlern hat - die sich ganz
einfach komplett vermeiden lassen. Man kann eben nicht alles auf einmal
haben. Das neue gcc-Paket ist doch der einzige Vorteil von 64 Bit.
> Man kann das Source Paket herunter laden und selbst kompilieren.
siehe oben
Bauform B. schrieb:> Jemand, der Angst vor neuen, heimtückischen Fehlern hat - die sich ganz> einfach komplett vermeiden lassen.
AMD64 ist etabliert genug dass man keine Angst mehr vor
Kinderkrankheiten haben muss... Oder was für heimtückische Fehler meinst
du? Für komplexe Projekte ist sogar ein 64bit GCC erforderlich weil die
32bit-Version nicht genug Speicher nutzen kann.
Bauform B. schrieb:> Harry L. schrieb:>> Damit kann man sich unter Linux sehr einfach jede gewünschte>> GCC-Toolchain bauen:>>>> https://crosstool-ng.github.io/>> Das scheint mir das gleiche zu sein, nur hübscher verpackt. Ob ich damit> besser klar komme?> Jedenfalls danke für die Tipps.
Ich kann dir wirklich nur dazu raten, das zu verwenden, wenn du deine
Toolchain aus den Sourcen selbst bauen willst.
Es ist ja nicht damit getan, den GCC zu bauen - das ist ja auch nur ein
Teil.
Da kommen noch einige andere Pakete dazu, und Crosstool kümmert sich
wirklich um Alles inkl. dem Download der erforderlichen Sourcen.
Ich bin schon lange Linuxer, aber würde es dieses Script nicht geben,
hätte ich mir sowas selbst bauen müssen. ;)
Starte das Script mit den passenden Parametern, geh in die Mittagspause,
und wenn du zurück kommst, ist deine Toolchain fertig.
Also, Debian ist klarer Testsieger. Seit einer Woche gibt es den
arm-none-eabi-gcc-7.3 in Debian-testing. Das Paket basiert auf der
Vorgängerversion der 8.x von arm.com, ist also praktisch "original" und
noch aktueller kann man nicht verlangen ;)
+ fertige Pakete für 10 Architekturen, z.B. i386, armhf = RPi bis s390
+ extrem einfache Installation wie alles von Debian
+ funktioniert stand-alone (newlib, gdb müssen nicht installiert sein)
- nicht aktuell
https://aur.archlinux.org/packages/gcc-arm-none-eabi-bin/
+ aktuell
- nur für x86_64
https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
+ Das Original
+ fertige Pakete für Mac OSX und Windows-32-Bit
+ aktueller geht's nicht
- ein großes Paket ohne Auswahlmöglichkeit
- kein Paket für 32-Bit-Linux
als Source:
+ anscheinend extrem einfach zu bedienen, falls man viel Zeit hat
- lässt sich nicht (so einfach) ohne newlib oder gdb bauen
- braucht viele spezielle Pakete auf dem host
https://github.com/FreddieChopin/bleeding-edge-toolchain
+ hat funktioniert
o das Script lies sich einfach auf "ohne newlib" umbauen
- dafür funktioniert beim Cortex-M0 keine Division
- keine Ahnung, wie original der gebaute gcc werden könnte
https://crosstool-ng.github.io/
+ das Schweizer Messer für Toolchain-Bastler
+ baut gcc für über zwei Dutzend Targets
+ benutzt menuconfig von kernel.org
+ ist frei konfigurierbar
- muss genau konfiguriert werden, auch wenn man ein sample benutzt
- ist nicht dafür gedacht, das Original von arm nach zu bauen
- die Lizenz ist etwas komplizierter
- hat sich nach wenigen Schritten selbst gelöscht
Niklas Gürtler schrieb:> AMD64 ist etabliert genug dass man keine Angst mehr vor> Kinderkrankheiten haben muss... Oder was für heimtückische Fehler meinst> du?
Fehler in eigenen Programmen, die aus einer Zeit stammen, als es noch
keine 64 Bit gab und die man bis jetzt nur einmal anfassen musste, als
errno.h eingeführt wurde.
Bauform B. schrieb:> Fehler in eigenen Programmen, die aus einer Zeit stammen, als es noch> keine 64 Bit gab und die man bis jetzt nur einmal anfassen musste, als> errno.h eingeführt wurde.
Dann kompiliert man seine eigenen Programme halt als 32bit.
STM32-Programme sind wenig überraschend auch immer nur 32bit. Dann kann
man trotzdem einen GCC nutzen der selbst AMD64 ist... Korrekt
geschriebenen C(++)-Programmen ist es komplett egal ob man jetzt für 8,
16, 32 oder 64bit kompiliert.
Thread beobachten
Seitenaufteilung abschalten