avr-gcc 6.1 unter Windows

[Fridolin (Gast)]

Hallo,

gcc 6.1 ist ja erschienen. Hat den avr-gcc jemand schon für Windows 
kompiliert? Hier gab es ja mal so einen Spezi, der das konnte und 
regelmäßig machte.

[Googlemalfuerdich (Gast)]

http://blog.zakkemble.co.uk/avr-gcc-6-1-0/

Keine Ahnung ob's funktioniert, weil Mangles Windows nie probiert...
Daufer mit Nachbauanleitung ;-)

[Fridolin (Gast)]

Hmm, ne, leider noch buggy.

Ich kompiliere mit -xc *.c

Raus kommt

avr-gcc: error: *.c: Invalid argument

Das ging definitiv mit allen früheren Versionen.

[Carl D. (jcw2)]

Fridolin schrieb:
> Hmm, ne, leider noch buggy.
>
> Ich kompiliere mit -xc *.c
>
> Raus kommt
>
>

avr-gcc: error: *.c: Invalid argument

>
> Das ging definitiv mit allen früheren Versionen.

Buggy ist dann aber der "Windows-Compiler-Driver".
Unter Linux geht der (selbstgebaute) avr-gcc 6.1, aber da löst die Shell 
auch den "*" auf und gibt die gefundenen Files an avr-gcc.

[Johann L. (gjlayde)]

Fridolin schrieb:
>

avr-gcc: error: *.c: Invalid argument

Sieht eher nach einem Problem der Umgebung / Shell aus denn Problem mit 
dem Compiler.  Was passiert mit zusätzlich -v ?

[Fridolin (Gast)]

D:\Atmel\test>d:\avr-gcc-6.1.0-x86-mingw\bin\avr-gcc.exe -v -xc *.c
avr-gcc.exe: error: *.c: Invalid argument
avr-gcc.exe: warning: '-x c' after last input file has no effect
Using built-in specs.
Reading specs from d:/avr-gcc-6.1.0-x86-mingw/bin/../lib/gcc/avr/6.1.0/device-specs/specs-avr2
COLLECT_GCC=d:\avr-gcc-6.1.0-x86-mingw\bin\avr-gcc.exe
COLLECT_LTO_WRAPPER=d:/avr-gcc-6.1.0-x86-mingw/bin/../libexec/gcc/avr/6.1.0/lto-wrapper.exe
Target: avr
Configured with: ../configure --prefix=/omgwtfbbq/win32 --target=avr --enable-languages=c,c++ --disable-nls --disable-li
bssp --disable-libada --with-dwarf2 --disable-shared --enable-static --host=i686-w64-mingw32 --build=x86_64-pc-linux-gnu

Thread model: single
gcc version 6.1.0 (GCC)

[Johann L. (gjlayde)]

Hast du einen 5.x zum Vergleich?

Beim 5.x funktioniert *.c wie gewohnt (win32), gen Fehler wie bei dir 
bekomme cih erst mit '*.c', d.h. wenn der * nicht durch die Shell 
ausgelöst wird und "*.c" als Dateiname interpretiert wird.

Erfolgt der Aufruf von Hand oder aus einem Script oder Makefile, und 
gibt es da Quotes um das *.c?

[Fridolin (Gast)]

Ich habe nur die offizielle gcc-Version von meinem Atmel Studio gegen 
die oben verlinkte gcc-Version getauscht. Ich vermute, dass derjenige, 
der sie kompiliert hat, irgendwas übersehen hat. Einen Parameter, eine 
spezielle Konfiguration, etc.
Aufruf aus Batch oder von der Kommandozeile, das macht keinen 
Unterschied. Genauso ob mit oder ohne "". Die Meldung ist immer die 
gleiche.
Tausche ich den gcc zurück gegen die offizielle Version, geht es wieder 
problemlos.

Ich kann die .c-Dateien einzeln angeben (abc.c xyz.c bla.c blubb.c 
usw.c), aber da baut mir der Compiler je nach Reihenfolge 
unterschiedlich große Binaries, fast immer größer als mit *.c trotz 
-flto. Warum das so ist, habe ich noch nicht verstanden.

[Fridolin (Gast)]

Hier hat jemand eine 5.x kompiliert, die das gleiche Problem hat.
Beitrag "AVR-GCC selbst bauen - Unter Linux für Windows?"
Vielleicht hilft das beim Eingrenzen des Fehlers?

[Felix P. (fixxl)]

Habe mir mit der Anleitung unter 
https://www.mikrocontroller.net/articles/AVR-GCC#Windows einen AVR-GCC 
6.1.0 selbst gebaut, der kann das *.c auch nicht auflösen. Ich habe 
leider keine Ahnung, was bei der Kompilierung für Windows genau abläuft, 
allerdings gibt es zahlreiche Warnings für *printf und/oder 
*scanf-Funktionen.

Für mich und meine Programme stört das nicht, da ich mit AVR-Eclipse 
arbeite und dort die Sourcefiles ohnehin immer einzeln aufgerufen 
werden.

Man kann sich unter Windows auch mit einer Batch-Datei unter Rückgriff 
auf den FOR-Befehl behelfen:

REM Compiler
for %%X in (*.c) do avr-gcc [OPTIONEN] %%~nX.c

REM BUILD CHAIN OF FILENAMES FOR LINKER
setlocal enabledelayedexpansion
SET foo=
for %%X in (*.o) do SET foo=!foo! %%~nX.o

REM Linker
avr-gcc [OPTIONEN] %foo%

Ansonsten kann ich den AVR-GCC 6.1.0 wirklich empfehlen. In Verbindung 
mit den Schaltern " -fno-tree-loop-optimize -fno-caller-saves" beim 
Compiler und "-mrelax" beim Linker wurde bei mir der Code teilweise 
deutlich kleiner als bei früheren Versionen.

[Fridolin (Gast)]

Ich kompiliere mit -flto, was nochmal deutlich etwas bringt. Dann müssen 
die .c-Dateien halt in einem Rutsch angegeben werden. Durch das Problem 
mit *.c ist mir aber erstmal bewusst geworden, dass die Reihenfolge eine 
Rolle spielt. Ich spare durch Umstellen teilweise 500 Bytes.

Tipp: Teste auch mal -mcall-prologues

[Felix P. (fixxl)]

Fridolin schrieb:
> Ich kompiliere mit -flto, was nochmal deutlich etwas bringt. Dann müssen
> die .c-Dateien halt in einem Rutsch angegeben werden. Durch das Problem
> mit *.c ist mir aber erstmal bewusst geworden, dass die Reihenfolge eine
> Rolle spielt. Ich spare durch Umstellen teilweise 500 Bytes.
>
> Tipp: Teste auch mal -mcall-prologues

-flto und -mcall-prologues habe ich schon auch mit drin. Trotzdem wird 
jedes c-File einzeln in ein o-File übersetzt, oder?

Edit: Habe es gerade getestet. Es spielt keine Rolle, ob man die Dateien 
alle hintereinander in einer Zeile dem Compiler übergibt oder ob man den 
Compiler einzeln für jede Datei aufruft. Der Output ist exakt derselbe.

[Bernd K. (prof7bit)]

Fridolin schrieb:
> Ich kompiliere mit -flto, was nochmal deutlich etwas bringt. Dann müssen
> die .c-Dateien halt in einem Rutsch angegeben werden.

Nein, Du musst lediglich folgendes beachten:

* Beim Compilieren jeder einzelnen .c Datei -flto angeben
* Beim Linken ebenfalls -flto angeben UND ebenfalls nochmal alle 
Optimierungsoptionen denn das letztendliche Optimieren wird dann bis zum 
eigentlichen Linkvorgang hinausgezögert (unter Zuhilfenahme der 
Zusatzinformationen die dann in den .o-Dateien drinstehen)

[Fridolin (Gast)]

Achso. Ne. Ich mache das alles in einem Rutsch.

-o blubb.elf

gcc compiliert und linkt, alles in einem Aufruf. Es werden keine 
.o-Dateien erstellt. Das passiert alles intern. Ich finde das viel 
praktischer so. Es erspart das ganze Gehampel mit mehreren Aufrufen und 
getrennten Compiler- und Linkerparametern.

Testet es mal, es geht super.

[Peter II (Gast)]

Fridolin schrieb:
> Ich finde das viel
> praktischer so.

bei kleinen AVR Projekten mag das gehen, bei größere Dinge freut man 
sich wenn nicht immer alles übersetzt werden muss

[Fridolin (Gast)]

Hier geht es aber nur um avr-gcc. ;))

[Johann L. (gjlayde)]

Felix P. schrieb:
> Habe mir mit der Anleitung unter
> https://www.mikrocontroller.net/articles/AVR-GCC#Windows einen AVR-GCC
> 6.1.0 selbst gebaut, der kann das *.c auch nicht auflösen. Ich habe
> leider keine Ahnung, was bei der Kompilierung für Windows genau abläuft,
> allerdings gibt es zahlreiche Warnings für *printf und/oder
> *scanf-Funktionen.

Grund für diese Warnungen ist vermutlich, dass dein Host-gcc eine andere 
Version hat als der damit erzeugte avr-gcc.  Idealerweise haben beide 
Compiler die gleiche (major) Version, hier also 6.x.

[Felix P. (fixxl)]

Danke für den Hinweis, Johann, werde mal schauen, dass ich den gcc unter 
Ubuntu aktualisiert bekomme. Da ist wirklich noch 5.x installiert!

Fridolin, kannst du mal deinen kompletten Aufruf für den Compile- und 
Linkvorgang mit allen Flags posten? Würde mich interessieren, wie das 
aussieht, ein simples Zusammenkopieren meiner getrennten Aufrufe 
funktioniert leider nicht.

[Fridolin (Gast)]

So z.B.

avr-gcc file1.c file2.c file3.c usw.c -mmcu=atmega328p 
-DF_CPU=20000000UL -flto -o blubb.elf

Weitere Optimierungsparameter usw. noch ergänzen.

Wenn es "nicht funktioniert", poste bitte mal die Fehlermeldung.

[Felix P. (fixxl)]

Fehlermeldung gibt es keine: Es wird schon eine Datei produziert. 
Allerdings zeigt die avr-size einen viel zu kleinen Wert für data (2% 
statt 18%) und nach dem Flashen hat das, was sich auf dem Controller 
abspielt, nichts mit dem gewollten Output zu tun, den ich bekomme, wenn 
ich Compiler und Linker getrennt aufrufe.

[Fridolin (Gast)]

Hmmmmmmm. Hänge mal

-Wall -Wextra

dran. Da muss doch irgendeine Warnung kommen.

[Yalu X. (yalu) (Moderator)]

Ich habe mal ein wenig zum Filename-Globbing recherchiert:

Der AVR-GCC für Windows wird mit der Mingw-Toolchain (das ist ein Paket
mit GNU-C-Compiler, -Assembler -Linker usw. mit Windows als Target)
gebaut. Das alte Mingw (offizieller Name MinGW) konnte nur 32-Bit-
Anwendungen, das neue (offizieller Name mingw-w64) kann sowohl 32- als
auch 64-Bit-Anwendungen erzeugen.

Bei beiden wird das Globbing über eine globale Variable (_CRT_glob bei
MinGW bzw. _dowildcard bei mingw-w64) in der Anwendung aktiviert. Der
Defaultwert dieser Variable war bei MinGW -1 (true), bei mingw-w64 ist
er 0 (false). Deswegen ist bei Anwendungen, die mit mingw-w64 erzeugt
werden, das Globbing normalerweise deaktiviert.

Da MinGW praktisch gestorben ist, gibt es für die meisten (alle?)
Linux-Distros nur noch mingw-w64. Man muss also sehen, wie man damit
zurecht kommt.

Um das Globbing zu aktivieren, muss man dafür sorgen, dass _dowildcard
in der Anwendung mit -1 initialisiert wird. Das kann entweder im
Quellcode oder durch das Hinzulinken der Datei CRT_glob.o (im
mingw-w64-Paket enthalten) geschehen. Bei selbstgeschriebenen Programmen
ist das das ganz einfach, bei der GNU-Toolchain, die ja aus mehreren
Einzeltools besteht, wird das schon etwas schwieriger. Man könnte
versuchen, CRT_glob.o durch entsprechendes einmaliges Setzen der
Environmentvariable LIBS jedem Linkeraufruf beim Bau der Toolchain
mitzugeben, schießt damit aber möglicherweise über das Ziel hinaus, da
es sicher auch Linkvorgänge gibt, wo dieses zusätzliche Objektfile
stören würde.

Um mehr Kompatibilität zum alten MinGW zu erhalten, kann man beim Bau
von mingw-w64 mit

  configure --enable-wildcard

dafür sorgen, dass das Globbing defaultmäßig aktiviert ist, so dass man
die GNU-Toolchain ohne irgendwelche Verrenkungen wie gewohnt bauen kann.
Bei Ubuntu würde das aber bedeuten, dass man das mingw-w64-Paket neu
bauen muss.

Bei Arch-Linux hingegen scheint das Globbing im mingw-w64-Paket
defaultmäßig aktiv zu sein. Vielleicht hat ja jemand Lust, die
AVR-GNU-Toolchain für Windows unter Arch-Linux zu bauen. Da sehe ich
gute Chancen, dass es mit dem Skript von Zak Emble funktionieren könnte.

Du könntest aber den AVR-GCC auch einfach von einer Bash aufrufen. Dann
übernimmt diese das Globbing. Wenn du bereits mit älteren GCC-Versionen
unter Windows gearbeitet hast, ist die Chance sogar groß, dass die Bash
bereits installiert ist.

[N. G. (newgeneration)]

Hallo Yalu,

toll wie du dass recherchiert hast!

Yalu X. schrieb:
> Vielleicht hat ja jemand Lust, die
> AVR-GNU-Toolchain für Windows unter Arch-Linux zu bauen.

Ich lasse das heute mal im Hintergrund laufen, melde mich bei Erfolg

[Bastian W. (jackfrost)]

Ich habs mal unter Gentoo mit minGW32 laufen lassen. Unter Win7 lief das 
avr-gcc mit -xc *.c. Die crtatmega8.o hat LD aber nur gefunden wenn die 
direkt bei den .c Dateien lag. Ich weiss nicht ob das eine 
Pfadeinstellung unter Windows ist oder ob das am compilieren lag.

Das Archiv liegt auf 
https://www.mainboardforum.de/eve-pictures/Win32.zip

Unter http://blog.zakkemble.co.uk/avr-gcc-6-1-0/ ist der Fehler aber 
scheinbar auch behoben.

Gruß JackFrost