avr-gcc-4.5.2 make-Problem

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

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

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