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.
http://blog.zakkemble.co.uk/avr-gcc-6-1-0/ Keine Ahnung ob's funktioniert, weil Mangles Windows nie probiert... Daufer mit Nachbauanleitung ;-)
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.
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 ?
1 | D:\Atmel\test>d:\avr-gcc-6.1.0-x86-mingw\bin\avr-gcc.exe -v -xc *.c |
2 | avr-gcc.exe: error: *.c: Invalid argument |
3 | avr-gcc.exe: warning: '-x c' after last input file has no effect |
4 | Using built-in specs. |
5 | Reading specs from d:/avr-gcc-6.1.0-x86-mingw/bin/../lib/gcc/avr/6.1.0/device-specs/specs-avr2 |
6 | COLLECT_GCC=d:\avr-gcc-6.1.0-x86-mingw\bin\avr-gcc.exe |
7 | COLLECT_LTO_WRAPPER=d:/avr-gcc-6.1.0-x86-mingw/bin/../libexec/gcc/avr/6.1.0/lto-wrapper.exe |
8 | Target: avr |
9 | Configured with: ../configure --prefix=/omgwtfbbq/win32 --target=avr --enable-languages=c,c++ --disable-nls --disable-li |
10 | bssp --disable-libada --with-dwarf2 --disable-shared --enable-static --host=i686-w64-mingw32 --build=x86_64-pc-linux-gnu |
11 | |
12 | Thread model: single |
13 | gcc version 6.1.0 (GCC) |
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?
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.
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?
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.
:
Bearbeitet durch User
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
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.
:
Bearbeitet durch User
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)
:
Bearbeitet durch User
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.
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
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.
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.
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.
Hmmmmmmm. Hänge mal -Wall -Wextra dran. Da muss doch irgendeine Warnung kommen.
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.