avr-gcc 6.1 unter Windows

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

1

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.

Fridolin schrieb:
>

1

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 ?

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?

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:

1

REM Compiler

2

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

3

4

REM BUILD CHAIN OF FILENAMES FOR LINKER

5

setlocal enabledelayedexpansion

6

SET foo=

7

for %%X in (*.o) do SET foo=!foo! %%~nX.o

8

9

REM Linker

10

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 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.

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)

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.

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.

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.

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.

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

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