Forum: Compiler & IDEs AVR Tool Chain mit MinGW


von Thomas Winkel (Gast)


Lesenswert?

Hallo Zusammen,
ich wollte mir gerade mit MinGW eine native AVR Entwicklungsplattform
für Windows basteln. Grundlage dafür ist die Dokumentation von
avr-libc:
http://www.nongnu.org/avr-libc/user-manual/install_tools.html
Vorher habe ich die beiden Dateien aus dem /bin Verzeichnis von
http://mesh.dl.sourceforge.net/sourceforge/gnuwin32/flex-2.5.4a-1-bin.zip
in den /bin Ordner von msys kopiert. Trotzdem bleibt make bei
checking for flex... flex
checking for yywrap in -lfl... no
checking for yywrap in -ll... no
checking lex output file root...
hängen. Der configure Vorgang läuft ohne zu meckern durch. Hat jemand
ne Ahnung, was ich falsch mache?

Danke, Thomas

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Ich bin alles andere als ein Windows-Experte...

Anyway, ich hatte das neulich auf Arbeit auf gleiche Weise probiert
und denselben Effekt beobachtet (ich glaube, es war beim avrdude).
Irgendwie rennt flex wohl aus dem MinGW-make heraus mit der
command.com-Umgebung ins Unendliche, bis es wegen
Ressourcenüberschreitung irgendwann abgewürgt wird.

Mit einem kleinen Hack hab' ich's hinbekommen: im config.log steht
in
der letzten Zeile das flex-Kommando, das er ausführen will.  Das führt
man mit der Hand aus, sodass configure den gewünschten Output zu sehen
bekommt.  Danach schießt man den ,,unendlichen'' flex mit dem task
manger ab, damit configure weiterläuft.  Zumindest habe ich avrdude
damit hinbekommen.

Ansonsten geht das, soweit ich Eric Weddington verstanden habe, wohl
nur dann alles richtig, wenn man nicht MinGWs (win32-)make benutzt,
sondern die Cygwin-Umgebung mit ihrem eigenen make (und ihrer eigenen
Shell, die da eine bash ist).  Dabei kann man die (meisten) Tools
dennoch so konfigurieren, dass sie als native Win32-Binaries arbeiten
und nicht über die Cygwin-Emulation, indem man (aus dem Kopf) beim
configure --build=i686-pc-mingw32 angibt.

Nicht umsonst steht bei avr-libc irgendwo im TODO-File noch herum:
``Document Windows Build guide.''

von Thomas Winkel (Gast)


Lesenswert?

Hallo und danke für deine Antwort! Das man unter Cygwin auch
Win32-Binaries erzeugen kann wusste ich noch nicht, werd das mal so
ausprobieren.
Gruß, Thomas

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Naja, du musst natürlich den MinGW-Compiler auf der Scheibe schon
drauf haben, sonst geht das nicht.  Die Cygwin-Umgebung dient
ausschließlich für den Rest, also make, shell, flex, bison.

von Thomas Winkel (Gast)


Lesenswert?

Das ist mir schon klar ;)
werd das morgen mal testen und dann hier berichten wies gelaufen ist.
So, schönen Feierabend,
Thomas

von Kai Klenovsek (Gast)


Lesenswert?

hier mal eine kleine Anleitung zu diesem Thema. Basiert allerdings auf
MinGW und MinSys. Mit Flex hatte ich allerdings noch keine Probleme.

http://kk.elektronik-4u.de/index.php?Sid=12

Ciao,
Kai

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Mit Flex hatte ich allerdings noch keine Probleme.

Ja, du nimmst ja auch MinSYS als Shell.  Ich denke, dass die
flex-Probleme, die sowohl Thomas als auch ich gesehen haben,
irgendwie am Zusammenspiel des MinGW32-make mit cmd.exe liegen.

von Kai Klenovsek (Gast)


Lesenswert?

Jab, hab ich übersehen.

@Thomas:
Der einfache Weg geht über MinGW und MinSys, einfach downloaden und die
Anweisungen auf meiner Seite befolgen. Dann sollte es kein Problem sein
die Toolchain für den AVR zu bauen.

Mit Cygwin sieht die Sache ein wenig anders aus da Du genau wissen
musst welche Libs und Tools du benötigst. Die werden nämlich nicht in
der Standardinstallation ausgeliefert. Dies kann im Zweifelsfall unter
Windows zu seltsamen Nebeneffekten führen.

Wieso willst Du das überhaupt selber machen?!? Ist doch schon alles
fertig.

Ciao,
Kai

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> Wieso willst Du das überhaupt selber machen?

Na, du hast es doch auch selbst machen wollen. ;-)

Im Ernst, wirklich schaden kann es nicht, wenn sich auch
Windows-Nutzer dran gewöhnen, dass man sich die Tools ja
durchaus auch selbst compilieren kann (und dass das am Ende
gar nicht mehr wirklich Aufwand ist).  Unter Unix ist das
seit Langem gang und gäbe.  So kann man eben auch mal schnell
einen Fehler selbst reparieren oder den Patch von jemandem
anders einspielen.

Apropos Patches: wenn jemand meinen persönlichen Patchkit für
avr-binutils und avr-gcc haben möchte, mit dem ich meine
FreeBSD-Ports baue (sind letztlich fast die gleichen Patches,
die auch Eric Weddington für WinAVR nimmt) => drop me a note.
Wenn's mehr als drei Leute interessiert, schiebe ich es auch
auf einen Webserver.  Patches gibt's derzeit für:

. binutils: AVR-COFF-Erzeugung (immer noch, VMLAB z. B. braucht's)
. binutils: ATtiny25/45/85, AT90PWM2/3, ATmega164/324/644,
            ATmega329/3290/649/6490, ATmega640/1280/1281
. GCC: 0bXXX binary constants
. GCC: ATtiny13/2313, ATtiny25/45/85, ATmega48/88/168, AT90PWM2/3,
       ATmega164/324/644, ATmega325/3250/645/6450,
       ATmega329/3290/649/6490, AT90CAN128

ATtiny13/2313, ATmega48/88/168, ATmega325/3250/645/6450 und AT90CAN128
sind zwar wohl im GCC-Source schon drin, aber noch nicht in den 3.4er
Versionen.

von Thomas Winkel (Gast)


Lesenswert?

Tach Zusammen,
ich arbeite von Anfang an schon unter MSYS, daran liegts also nicht.
Mir ist aber aufgefallen, dass ein "flex --help" unter MSYS keinen
Output liefert und die Console einfrieren lässt, während dieses unter
cmd.exe funktioniert. Trotzdem bringt ein make unter cmd den gleichen
Fehler wie in MSYS. Eigentlich hab ich alles genau so gemacht wie auf
Kais Homepage beschrieben, nur halt in einem extra Verzeichnis wie es
im avr-libc Manual steht.
Mit Cygwin klappts bei mir auch nicht, erst meckert er, dass er
"i686-pc-cygwin-ar" nicht findet und wenn ich dann einen
entsprechenden symbolischen link auf "/usr/i686-pc-cygwin/bin/ar.exe"
anlege kann er die Objektdateien nicht linken (undefined symbols not
allowed in i686-pc-cygwin shared libraries). Ich frag mich sowiso was
der mit i686-pc-cygwin will, wenn ich für i686-pc-mingw32 configuriert
habe...
Unter linux funktioniert die Vorgehensweise übrigens wunderbar (nur um
mal eben ein Erfolgserlebnis zu vermelden ;)).
Warum ich das selber machen will? Weil ich gerade bei einer
Entwicklungsumgebung gerne genau wissen würde wo was ist und wie das
alles zusammenarbeitet. Außerdem kommen später noch andere Targets
hinzu (PowerPC und villeicht ARM) und da hätte ich gerne alles zentral
und übersichtlich an einem Ort, und nicht überall doppelt und dreifach
im System verstreut.
Gruß, Thomas

von Kai Klenovsek (Gast)


Lesenswert?

Das sich die Shell öfter mal weghängt ist mir bekannt. Das nervt
manchmal ein wenig. Wenn Du unter Cygwin arbeitest musst Du auf
jedenfall das x:\cygwin\bin Verzeichnis in Deine Path-Enviroment
Variable adden, sonst geht gar nichts.

Dein Flex --help Problem kann ich hier nicht nachvollziehen.

Das mit dem Host verstellen auf i686-pc-mingw32 unter Cygwin hab ich
noch nicht gemacht, da mich die Dll Abhängigkeiten nicht stören, werde
ich aber auf jedenfall mal testen und berichten.

Mein Tip zu Deinem Problem ist, dass Du noch einmal alles von der
Platte schmeisst was mit Cygwin, MinGW und MinSys zu tun hat. Lösche
auch alle Path Variablen. Danach einen altbewährten Neustart einleiten
und alles noch einmal so durchgehen wie auf meiner Seite beschrieben.
Lässt Du nur einen Punkt aus oder wechselst die Reihenfolge geht es auf
keine Fall. Zum testen solltest Du auch den Output im Standard
Verzeichnis belassen.

Ciao,
Kai

von mthomas (Gast)


Lesenswert?

Nutze auch MinGW/mSYS fuer WinARM. Es ist allerdings eine etwas aeltere
Installation der Tools, bin also moeglicherweise nicht auf neustem
Stand. Flex wurde seinerzeit einfach aus dem WinAVR-Utils-Verzeichnis
in das bin-Verzeichnis der "Unixemulation" kopiert. Ursache fuer das
Flex-Problem sind mglw. einfach nur verschiedene Versionen. Vielleicht
sind auch mehrere flex.exe installiert und im Suchpfad
(mingw/minsys/cygwin/WinAVR). So wirklich viel hat sich bei den Tools
wohl nicht getan, eine alte flex-Version muesste ausreichen (reicht
"hier" zumindest fuer arm-elf-binutils/-gcc/newlib).

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Bei mir zumindest war das kein Problem mit dem flex an sich.  Er
verklemmte sich ja nur aus dem configure heraus, während er,
separat aufgerufen, funktioniert hat.

von Werner B. (Gast)


Lesenswert?

Was ich über das flex problem rausgefunden habe:

  es hängt, wenn es in /x/msys/bin installiert bzw. kopiert wird, ist
es nach /x/MinGW/bin verschoben geht es einwandfrei!

von Thomas Winkel (Gast)


Lesenswert?

Tatsache! So gehts, das ist ja krass...
Ich habe übrigens keine GNU Verzeichnisse in der Windows PATH Variable,
die sperr ich in den Shell Umgebungen ein, da kommt dann auch nichts
durcheinander.
Rock'n'Roll,
Thomas

von Kai Klenovsek (Gast)


Lesenswert?

Werde das heute Abend auf meiner Seite ändern obwohl ich das Problem
immer noch nicht nachvollziehen kann.

Ciao,
Kai

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
Noch kein Account? Hier anmelden.