Hallo, ich arbeite erst seit kurzem unter Linux (Fedora 13). Nun will ich mir die AVR-Toolchain installieren. Ich habe nach Anleitung (http://www.nongnu.org/avr-libc/user-manual/install__tools.html) die Binutils (2.21), den GCC (4.5.2) und die AVR-Libc runtergeladen. Die aktuellen Binutils habe ich installiert. Aber das Kompilieren des gcc scheitert jedes Mal mit: ... Adding multilib support to Makefile in ../../.././libgcc with_multisubdir=avr6 make[2]: Entering directory `/export/scratch/gcc-4.5.2/avr/libgcc' Makefile:154: ../.././gcc/libgcc.mvars: Datei oder Verzeichnis nicht gefunden make[2]: *** Keine Regel, um »../.././gcc/libgcc.mvars« zu erstellen. Schluss. make[2]: Leaving directory `/export/scratch/gcc-4.5.2/avr/libgcc' make[1]: *** [all-target-libgcc] Fehler 2 make[1]: Leaving directory `/export/scratch/gcc-4.5.2' make: *** [all] Fehler 2 Kann sich jemand (Jörg Wunsch?) die Ursache vorstellen. Ich habe auch Vorgängerversionen (GCC 4.4.5, 4.5.0, 4.5.1) probiert. Es scheitert immer an der gleichen Stelle.
. Wie lautet genau dein configure-Kommando? . Hast du das configure und make, wie beschrieben, in einem Verzeichnis ausgeführt, das nicht das GCC-Stammverzeichnis ist?
Mein configure-Kommando lautet: ./configure --target=avr --prefix=/export/scratch/avr --disable-nls -enable-language=c,c++ --disable-libssp -with-dwarf2 Wo steht das man das man nicht das Stammverzeichnis benutzen darf? Danke für deine Hilfe...
Ok, die Frage zwei habe ich gerade in den Install Manuals gefunden: ... First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported. ... Wer lesen kann ist klar im Vorteil... :) make läuft gerade, mal sehen obs klappt...
so, es ist schon etwas besser, er ist weitergelaufen, aber an der Stelle: ... checking whether symbol versioning is supported... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libgfortran] Fehler 1 make[1]: Leaving directory `/export/scratch/gcc-build' make: *** [all] Fehler 2 hängengeblieben. Fällt die dazu was ein? Danke Mario
Ok, Problem gelöst: Ich hatte noch einen Fehler in den configure Optionen, richtig ist es so: ./configure --target=avr --prefix=/export/scratch/avr --disable-nls --enable-languages=c,c++ --disable-libssp -with-dwarf2
Ein neues Problem, jetzt bei der Installation von avr-libc-1.7.0: ... viele Zeilen In file included from ../../../../common/macros.inc:39:0, from ../../../../crt1/gcrt1.S:38: ../../../../include/avr/io.h:422:6: warning: #warning "device type not defined" ../../../../crt1/gcrt1.S: Assembler messages: ../../../../crt1/gcrt1.S:53: Error: non-constant expression in ".if" statement ../../../../crt1/gcrt1.S:54: Error: non-constant expression in ".if" statement ...viele Zeilen gleichen Inhalts ../../../../crt1/gcrt1.S:178: Error: non-constant expression in ".if" statement ../../../../crt1/gcrt1.S:179: Error: non-constant expression in ".if" statement make[5]: *** [gcrt1.o] Fehler 1 make[5]: Leaving directory `/export/scratch/avr-libc-1.7.0/avr/lib/avr25/attiny2313a' make[4]: *** [all-recursive] Fehler 1 make[4]: Leaving directory `/export/scratch/avr-libc-1.7.0/avr/lib/avr25' make[3]: *** [all-recursive] Fehler 1 make[3]: Leaving directory `/export/scratch/avr-libc-1.7.0/avr/lib' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/export/scratch/avr-libc-1.7.0/avr' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/export/scratch/avr-libc-1.7.0' make: *** [all] Fehler 2 Was könnte das bedeuten?
Mario Grafe schrieb: > Was könnte das bedeuten? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261 Workaround: lösch den entsprechenden Test für ATtiny2313A aus dem configure-Script der avr-libc, oder nimm im GCC selbst die im Bugreport vorgeschlagene Änderung (ein fprintf() in ein error() ändern) vor.
Mario Grafe schrieb: > First, we highly recommend that GCC be built into a separate directory > from the sources which does not reside within the source tree. Es funktioniert übrigens auch, wenn man innerhalb des source trees ein Unterverzeichnis anlegt (z. B. "build") und dann daraus das configure mit ../configure aufruft.
Mario Grafe schrieb: > Ok, Problem gelöst: Ich hatte noch einen Fehler in den configure > Optionen, richtig ist es so: > > ./configure --target=avr --prefix=/export/scratch/avr --disable-nls > --enable-languages=c,c++ --disable-libssp -with-dwarf2 Nö, du rufst confugure offenbar im Quellverzeichnis auf. Zum Build hat man drei Verzichnisse, wobei keines ein Unterverzeichnis eines anderen ist. - Quelle - Build - Install Für dwarf2 heisst's ausserdem --with-dwarf2, zumindest die 4.5.0 hat sich nicht damit erzeugen lassen ohne avr.c zu patchen, weil ein notwendiger dwarf-Hook vom avr-Backend nicht implementiert war/ist und ich seh auch kein Patch diesbezüglich.
Mit dem avr.c-Patch von Jörg Wunsch hats geklappt (das kompilieren der avr-libc meine ich). Jetzt habe ich aber das Problem, dass trotz aktuellsten binutils, avc-gcc und avr-libc keine atxmega unterstützt werden (gerade die brauche ich). Gibts für die atxmega-Unterstützung auch einen Patch? Sorry für die vielleicht blöden Fragen aber ich bin wirklich ein Newbie was Linux angeht. Es ist sehr mühsam sich alles aus verschiedenen Quellen zusammenzufrickeln... Danke für eucre Hilfe
> Es ist sehr mühsam sich alles aus verschiedenen > Quellen zusammenzufrickeln... Warum machst du das überhaupt? Muss es denn unbedingt der gcc 4.5 sein? http://www.mikrocontroller.net/articles/AVR_und_Linux
Durch den Artikel habe ich mir schon durchgelesen. Man muß sich trotzdem die Quellen runterladen und kompilieren. Durch diverse Abhängigkeiten und Bugs ist das alles andere als trivial und erklärt auch nicht die Fragen die ich gestellt habe.
Und warum benutzt du nicht das dort verlinkte Skript von Bingo, das sich eigentlich um alles kümmert, oder gleich die fertigen deb-Pakete?
Mario Grafe schrieb: > Mit dem avr.c-Patch von Jörg Wunsch hats geklappt (das kompilieren der > avr-libc meine ich). Jetzt habe ich aber das Problem, dass trotz > aktuellsten binutils, avc-gcc und avr-libc keine atxmega unterstützt > werden (gerade die brauche ich). > > Gibts für die atxmega-Unterstützung auch einen Patch? Es gibt eine ganze Latte an Patches. Ob die auf gcc 4.5 passen ist allerdings ne andere Frage. Da die avr-gcc-Entwicklung praktisch daniederliegt und es daher schon nen Strich am Kalender Wert ist, wenn da was weitergeht, stehen die Chancen dazu ganz gut. http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631 Soweit ich sehen kann sind da aber keine Patches für einige kritische Fehler, d.h. stillschweigend falsche Codegenerierung. Freilich sind einige der Bugs schon länger drinne, eben mindestens so lange wie nicht mehr an avr weiterentwichkelt wird... > Es ist sehr mühsam sich alles aus verschiedenen > Quellen zusammenzufrickeln... Ja, das ist es. Eben nix für Mädchen ;-)
Im aktuellen AVR32 Studio 2.7 (http://www.atmel.no/beta_ware/) ist anscheinend auch die Toolchain für die 8bitter mit drin (verpackt in einem Eclipse-Plugin zusammen mit der AVR32 Version). Und zwar sowohl in der Windows- als auch der Linux-Version. Aus der Eclipse-IDE selbst läßt sich das allerdings mangels passender Integration leider noch nicht so einfach nutzen (zumindest unter Windows nicht, Linux hab ich nicht getestet)
Stefan Ernst schrieb: > Und warum benutzt du nicht das dort verlinkte Skript von Bingo, das sich > eigentlich um alles kümmert, oder gleich die fertigen deb-Pakete? Ich wollte das Bingo-Script nicht nehmen da ich gerne die aktuellste Version aller drei Komponenten haben wollte. Die deb-Pakete kann ich nicht nehmen. Bei Heise/c't habe ich auch noch eine Anleitung gefunden, allerdings fehlt dort noch der avr.c patch (http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain) Johann L. schrieb: > Ja, das ist es. Eben nix für Mädchen ;-) Ja da ist wohl wahr. Ich bin Windows verweichlicht. Mit der Kommandozeile habe ich mich das letzte mal zu DOS-Zeiten beschäftigt...
Mario Grafe schrieb: > Die deb-Pakete kann ich nicht nehmen. Warum nicht? Weil kein Debian-Paket-Management installiert ist? Du brauchst doch lediglich den Inhalt des Pakets, einfaches Auspacken (mit ar und tar) reicht doch. > Bei Heise/c't habe ich auch noch eine Anleitung gefunden, allerdings > fehlt dort noch der avr.c patch > (http://www.heise.de/ct/projekte/machmit/ctbot/wiki/AVRToolchain) Das ist dann aber auch "nur" der gcc 4.3. > ... da ich gerne die aktuellste > Version aller drei Komponenten haben wollte. Na dann ... viel Glück.
Mario Grafe schrieb: > Gibts für die atxmega-Unterstützung auch einen Patch? Ja, bei WinAVR bzw. den Atmel AVR Tools. Aber sehr wahrscheinlich noch nicht auf 4.5.x portiert, sondern maximal 4.4.x. Diese Patches sind aus diversen juristischen Gründen (und vermutlich auch zeitlichen Engpässen bei Atmel) noch nicht in den GCC-Tree gewandert.
Jörg Wunsch schrieb: > Ja, bei WinAVR bzw. den Atmel AVR Tools. Aber sehr wahrscheinlich > noch nicht auf 4.5.x portiert, sondern maximal 4.4.x. > > Diese Patches sind aus diversen juristischen Gründen (und vermutlich > auch zeitlichen Engpässen bei Atmel) noch nicht in den GCC-Tree > gewandert. Vielen Dank Jörg, du hast mir sehr geholfen. Ich habe mir jetzt die Toolchain mit der Anleitung von Heise/C't zusammengebastelt und mit dem avr.c-Patch von dir ergänzt. Die Toolchain ist zwar nicht topaktuell aber unterstützt alle Controller (xmega) die ich brauche. Ich habe es getestet, es funktioniert jetzt alles wunderbar. Gruß Mario
Pas auf du brauchst einer andere util/delay.h mit avrlibc-1.7.0 http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=766404#766404 Ich meine Jörg hast die datei auch im diser forum macht .. Sind deiner version neuere als diser ? http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=95328 mfg Bingo Dänemark
Bingo schrieb: > Pas auf du brauchst einer andere util/delay.h mit avrlibc-1.7.0 > http://www.avrfreaks.net/index.php?name=PNphpBB2&f... Danke, ich habe die delay.h ersetzt...
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.