Hallo Forum,
kleine Frage:
Wie kann ich am einfachsten den GCC fürs target AVR bauen?
Imho müsste es am einfachsten unter Linux gehen. Also mithilfe von
mingw32.
(Unter 1) steht auch wie es unter Windows gehen sollte, aber das
erscheint mir um einiges Umständlicher und ich habe normalerweise kein
Problem mit Linux)
Also schnell Ubuntu in ner Virtuellen Maschine installiert und auch
ming32 (x86_64-w64-ming32-gcc etc.)
nur bin ich mir nicht sicher, wie ich damit jetzt die Windows-Binaries
bauen kann.
Ich dachte zuerst an
configure: WARNING: If you wanted to set the --build type, don't use --host.
2
If a cross compiler is detected then cross compile mode will be used.
Also sollte ich wohl --build nehmen. Damit kommt allerdings folgender
Fehler:
1
checking for library containing strerror... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
Also wie lauten die richtigen Befehle oder wie macht man es richtig?
mit freundlichen Grüßen,
N.G.
PS: die Tools sind:
avrdude aus dem aktuellen svn-trunk
avr-libc aus dem aktuellen svn-trunk
binutils-2.25
gcc-5.3.0
1) http://www.nongnu.org/avr-libc/user-manual/install_tools.html
Als erstet benötigst du einen mingw32-gcc im Pfad, den hast du ja wohl
schon.
Dann benötigst du eine native Cross-Toolchain, also einen avr-gcc
inclusive Binutils und avr-libc, und zwar Version 5.3.0; am besten auch
im Pfad. Hast du den?
Und wiedo überhaupt 5.3.0 und nicht 5.3.1. 5.3.0 ist doch nur ein
Release Candidate?
Außerdem kommt
1a) configure der native avr-binutils
1b) build der native avr-binutils
1c) install der native avr-binutils
2a) run ./contrig/download_prerequisites (nach cd GCC_SOURCE)
2b) configure des native avr-gcc mit gleicher prefix wie 1a)
2c) build des native avr-gcc
2d) install des native avr-gcc
3a) bootstrap avr-libc von SVN trunk
3b) configure avr-libc mit prefix wie 1a)
3c) build avr-libc
3d) install avr-libc
===================================================
avr-gcc von oben in pfad aufnehmen
4a) configure der canadian avr-binutils, gleiche quellen wie 1)
4b) build der canadian avr-binutils
4c) install der canadian avr-binutils
5a) configure des canadian avr-gcc, quellen wie 2) prefix wie 4)
5b) build des canadian avr-gcc
5c) install des canadian avr-gcc
6a) gehe ins build der avr-libc von 3)
6b) make install prefix=`prefix wie 4) bzw. 5)`
configure IMMER außerhalb des Quellbaums
Könntest du die 5.3.1 für Windows nach getaner Arbeit für die
Allgemeinheit zur Verfügung stellen? Dann bräuchte nicht jeder das Rad
neu erfinden. Vielen Dank. :o)
Fridtjof Gärtner schrieb:> Könntest du die 5.3.1 für Windows nach getaner Arbeit für die> Allgemeinheit zur Verfügung stellen? Dann bräuchte nicht jeder das Rad> neu erfinden. Vielen Dank. :o)
Ja, natürlich. Mir stellt sich gerade nur die Frage: Wo?
Muss mal noch etwas überlegen.
Davor muss ich aber erst mal noch den Compiler fertig bauen (dauert auf
meinem Rechner + virtuelle Maschine ewig) und dann noch testen.
Aber soweit schaut der build nach Johanns Anleitung gut aus.
Ich melde mich wenn es fertig und getestet ist
Okay, zum aktuellen Stand:
Danke Johann, deine Anleitung war Gold wert!!!
Es hat funktioniert.
Ich habe mir erlaubt diese ein wenig ausführlicher zu schreiben und
unter AVR-GCC hier im Forum zu veröffentlichen.
Eventuell schaust du ja mal kurz drüber, ob sich nicht doch noch ein
Fehler eingeschlichen hat, ich habe die Anleitung nämlich gerade erst,
also schon einige Stunden nach dem eigentlichen Erstellen,
geschrieben...
Ich habe mal kurz einige meiner Programme kompiliert und es kam zu
keinen Fehlern, schon mal gut.
Danach habe ich mal mit csmith (ein Programm, das per Zufall C-Programme
erzeugt) einige Programme getestet, von 1000 Durchläufen kam es nur bei
4 zu folgendem Fehler: address 0x810036 of a.out section `.bss´ is not
within `data´
Also nur ein Fehler, dass der Speicher zu klein war.
(Dazu kamen noch ca. 10000000 und 1 Fehler dass die Bitbreite bei
structs größer war als ihr Typ bits hatte (etwas so: struct x {unsigned
y:30}; was auf dem AVR natürlich zum Fehler führt))
Ich schaue mal wo ich am besten "meinen" GCC veröffentliche...
N. G. schrieb:> Dazu kamen noch ca. 10000000 und 1 Fehler dass die Bitbreite bei> structs größer war als ihr Typ bits hatte (etwas so: struct x {unsigned> y:30}; was auf dem AVR natürlich zum Fehler führt))
Das ist dann offenbar entweder ein Lapsus in csmith, oder eine falsche
Konfiguration von csmith. Ist doch wohl das mindeste, dass sizeof(int)
eingestellt werden kann?
Funktioniert LTO mit Leerzeichen im Installationspfad(*) und ähnliche
Scherze?
Prefix würd ich immer ohne solche Kapriolen wählen. Die Installierte
Toolchain lässt sich ja einfach in nen anderen Ordner verschieben.
Johann L. schrieb:> N. G. schrieb:>> Dazu kamen noch ca. 10000000 und 1 Fehler dass die Bitbreite bei>> structs größer war als ihr Typ bits hatte (etwas so: struct x {unsigned>> y:30}; was auf dem AVR natürlich zum Fehler führt))>> Das ist dann offenbar entweder ein Lapsus in csmith, oder eine falsche> Konfiguration von csmith. Ist doch wohl das mindeste, dass sizeof(int)> eingestellt werden kann?
Keine Ahnung, fiel bei mir auch direkt unter "schlechter Stil", aber ist
ja nicht wirklich von belang
Johann L. schrieb:> Funktioniert LTO mit Leerzeichen im Installationspfad(*) und ähnliche> Scherze?>> Prefix würd ich immer ohne solche Kapriolen wählen. Die Installierte> Toolchain lässt sich ja einfach in nen anderen Ordner verschieben.
LTO funktioniert, habe ich aber nur in einem Projekt bisher überhaupt
benutzt. Dort läuft es aber fehlerfrei.
Leerzeichen im Pfad benutze ich generell nicht, schließlich sind wir
Programmierer und kommen ohne diesen Schnickschnack (Leerzeichen,
Umlaute, etc.) aus.
Kann ich aber nachher mal testen
Johann, du bist doch an der gcc-Entwicklung beteiligt. Wenn ich das
richtig verstanden habe? Und du weißt wie es geht und oder hast es in
der Vergangenheit schon mal gemacht. Kannst du nicht deine aktuelle
Windows-Version mal zur Verfügung stellen? Das wäre sehr nett. :o)
Karl Napp schrieb:> Und? Gibt es neue Erkenntnisse?
Ja, alles was ich getestet habe funktioniert.
Ich muss jetzt nur noch ne vernünftige Seite finden wo ich die GCCs (32
und 64bit zum download stellen kann)
Bin zur Zeit eh nicht daheim, Weihnachten und Familie geht vor
Lena Schmidt schrieb:> Kannst du nicht deine aktuelle Windows-Version mal zur Verfügung> stellen? Das wäre sehr nett
Hallo Lena,
das mache ich schon ;)
Bald...
Hallo,
ich war über den Jahreswechsel nicht daheim, deswegen melde ich mich
erst jetzt...
Ich habe noch keinen passenden Hoster für die Files gefunden (habe aber
noch nicht gesucht ;) ), aber auf deine Bitte hin hab ich die beiden
Compiler (win32 und win64) mal in meine Dropbox gepackt. Links sind
unten, ich kann nur nicht versprechen, dass diese ewig gültig bleiben.
Wenn ich die Files mal bei einem richtigen (vertraueswürdigen, guten)
Hoster hochgeladen habe, melde ich mich hier wieder.
mfG
N.G.
https://www.dropbox.com/s/q6nahkv9d46p3ks/avr-gcc-5.3.1-win32.tar.bz2?dl=0https://www.dropbox.com/s/b9wjk6k5w790rff/avr-gcc-5.3.1-win64.tar.bz2?dl=0
Die Version an sich hat damit nichts zu tun. Möglicherweise habe ich
bein erzeugen des 32bit-gccs einen Fehler gemacht. Ich habe jetzt auch
mal beide Windowsversionen getestet und es hat sich der selbe Fehler
eingestellt.
Nur ich wüsste nicht, wieso ein bestimmtes Kommandozeilenargument fehlen
sollte
Karl Napp schrieb:> Ich wüsste nicht, was die Bittigkeit damit zu tun hätte. Ich verwende> ein 32-Bit-Windows.>> avr-gcc: error: *.c: Invalid argument
Das"*.c" wird von einer Unix-shell eben zu "alle c-Files im aktuellen
Verzeichnis" expandiert. CMD.EXE hat das nicht!
Carl D. schrieb:> Karl Napp schrieb:>> Ich wüsste nicht, was die Bittigkeit damit zu tun hätte. Ich verwende>> ein 32-Bit-Windows.>>>> avr-gcc: error: *.c: Invalid argument>> Das"*.c" wird von einer Unix-shell eben zu "alle c-Files im aktuellen> Verzeichnis" expandiert. CMD.EXE hat das nicht!
Nein, das sollte funktionieren.
Tut es zumindest bei mir ;)
Ich glaube ich habe den Fehler:
ich habe doch die Anleitung im Artikel avr-gcc geschrieben, und diese
enthielt einen Fehler, den ich einen Tag später ausgebessert habe. Es
fehlte --enable-languages=c,c++,lto
Wenn ich beim Bauen des win32-avr-gcc das auch vergessen habe dürfte
klar sein, warum es nicht geht...
N. G. schrieb:> Carl D. schrieb:>> Karl Napp schrieb:>>> Ich wüsste nicht, was die Bittigkeit damit zu tun hätte. Ich verwende>>> ein 32-Bit-Windows.>>>>>> avr-gcc: error: *.c: Invalid argument>>>> Das"*.c" wird von einer Unix-shell eben zu "alle c-Files im aktuellen>> Verzeichnis" expandiert. CMD.EXE hat das nicht!>> Nein, das sollte funktionieren.> Tut es zumindest bei mir ;)
Via Cygwin-bash?
Carl D. schrieb:> N. G. schrieb:>> Carl D. schrieb:>>> Karl Napp schrieb:>>>> Ich wüsste nicht, was die Bittigkeit damit zu tun hätte. Ich verwende>>>> ein 32-Bit-Windows.>>>>>>>> avr-gcc: error: *.c: Invalid argument>>>>>> Das"*.c" wird von einer Unix-shell eben zu "alle c-Files im aktuellen>>> Verzeichnis" expandiert. CMD.EXE hat das nicht!>>>> Nein, das sollte funktionieren.>> Tut es zumindest bei mir ;)>> Via Cygwin-bash?
Tut mir leid, was das angeht: ich habe keine Ahnung obs mit oder ohne
Cygwin/MSYS64 geht. Alle meine Windows PCs sind damit "verseucht". Kann
also wirklich daran liegen
...ich frag mich warum dein avr-gcc so riesig ist? Das BZ2 bei dropbox
hat ca. 170 MB.
Mein avr-gcc-5.2 (incl. Binutils und aller Libs) hat als ZIP weniger als
43 MB, dein avr-gcc ist also 3x größer!
--enable-languages=c,c++ genügt. Ohne diese Option wird für alle
verfügbaren Sprachen generiert, allerdings weiß ich nicht auswendig ob
das überhaupt funktioniert und dann z.B. Java, Ada etc. deaktiviert
sind.
Johann L. schrieb:> ...ich frag mich warum dein avr-gcc so riesig ist? Das BZ2 bei dropbox> hat ca. 170 MB.>> Mein avr-gcc-5.2 (incl. Binutils und aller Libs) hat als ZIP weniger als> 43 MB, dein avr-gcc ist also 3x größer!
Tja, das frage ich mich auch...
Woran kann das liegen? (Schuss ins blaue: vllt Optimierung beim
Kompilieren vergessen?)
WinAVR hat aber auch 300MB, allerdings ist da ja noch etwas zusätzliches
(wie zB pn) dabei
Hier mal die Ordner (Unkomprimiert: 720MB!) nach Größe aufgeschlüsselt:
Hier ist der von dir verwendete --host wohl zu neu oder etwas anderes
ist mit deiner Toolchain resp. cross-host Umgebung nicht ok. M$ ist
dafür bekannt sich bei xprintf nicht an die Spezifikationen zu halten;
z.B. bei den Rückgabewerten.
N. G. schrieb:> Johann L. schrieb:>> ...ich frag mich warum dein avr-gcc so riesig ist? Das BZ2 bei dropbox>> hat ca. 170 MB.>>>> Mein avr-gcc-5.2 (incl. Binutils und aller Libs) hat als ZIP weniger als>> 43 MB, dein avr-gcc ist also 3x größer!
...das bezieht sich auf deine 32-Bit Version.
Der Unterschied rührt von den EXE her. Meine Toolchains strippe ich
damit sie nicht so riesig werden. Mit Symbol-Info kann da eh niemand
was anfangen:
> Woran kann das liegen? (Schuss ins blaue: vllt Optimierung beim> Kompilieren vergessen?)
Unwahrscheinlich. Es sei denn du hast explizite ohne Optimierung
übersetzt. Wobei nicht nur cc1.exe, lto1.exe und cc1plus.exe größer
sind, sondern auch z.B. avr-strip.exe etc.
Okay, neuer Versuch:
Danke Johann, ich habs mal mit deinem Code gestript: Gepackt 30MB!
Sehr schön.
Ich hab den Compiler gerade nocheinmal ganz neu gebaut. Frische Sourcen
von heute.
Johann, kannst du nochmal das Projekt von heute kompilieren, ob der
selbe Fehler nochmal kommt?
Karl Napp, wie siehts damit bei dir aus?
Auch der Rest ist herzlich zum testen eingeladen :)
Der Link:
https://www.dropbox.com/s/q6nahkv9d46p3ks/avr-gcc-5.3.1-win32.tar.bz2?dl=0
Nope.
avr-gcc: error: *.c: Invalid argument
avr-gcc: warning: '-x c' after last input file has no effect
avr-gcc: fatal error: no input files
compilation terminated.
N. G. schrieb:> Johann, kannst du nochmal das Projekt von heute kompilieren, ob der> selbe Fehler nochmal kommt?
Ja, immer noch Fehler mit asprintf in avr/bin/ld.exe.
Johann L. schrieb:> N. G. schrieb:>> Johann, kannst du nochmal das Projekt von heute kompilieren, ob der>> selbe Fehler nochmal kommt?>> Ja, immer noch Fehler mit asprintf in avr/bin/ld.exe.
Zur Info: Das Problem mit dem asprintf ist in v6.5+ und v7.2+ behoben:
https://gcc.gnu.org/PR81487
