Configure läuft durch und make bricht mit folgenden Meldungen ab:

...
rm gcc.pod
make[2]: Leaving directory `/tmp/gcc/gcc'
Checking multilib configuration for libgcc...
mkdir -p -- avr/libgcc
Configuring in avr/libgcc
configure: creating cache ./config.cache
checking for --enable-version-specific-runtime-libs... no
checking for a BSD-compatible install... /usr/bin/install -c
checking for gawk... gawk
checking build system type... x86_64-unknown-linux-gnu
checking host system type... avr-unknown-none
checking for avr-ar... avr-ar
checking for avr-lipo... avr-lipo
checking for avr-nm... /tmp/gcc/./gcc/nm
checking for avr-ranlib... avr-ranlib
checking for avr-strip... avr-strip
checking whether ln -s works... yes
checking for avr-gcc... /tmp/gcc/./gcc/xgcc -B/tmp/gcc/./gcc/ -B/usr/local/avr/avr/bin/ -B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/include -isystem /usr/local/avr/avr/sys-include   
checking for suffix of object files... configure: error: in `/tmp/gcc/avr/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory `/tmp/gcc'
make: *** [all] Error 2

Als Anhang der avr/libgcc/config.log, auf den in der Fehlermeldung 
verwiesen wird.

Die 4.6.0 konnte ich schonmal auf der Maschine generieren - die führt 
mittlerweile zum selben Abbruch.

Ich habe folgende Kommandos aus einem Verzeichnis ausgeführt, das neben 
der Wurzel des Quellbaums liegt:

export PREFIX=/usr/local/avr-4.6.1
export PATH=$PATH:$PREFIX/bin
../gcc-4.6.1/configure  --target=avr --prefix=/usr/local/avr --disable-nls --enable-languages=c --disable-libssp
make

Was kann das sein?

1) --prefix=/usr/local/avr
   SOWAS MACHT MAN NICHT
   Es sei denn man legt es auf Ärger an, zB falls es bereits eine
   Installation mit dem default(!) prefix /use/local gibt.

2) Welchen Assembler verwendest du?

3) gmp, mpfr, mpc hast du

4) Welchen Wert hat $CC?

5) Bitte das richtige config.log anhängen.

Wie passt

> export PREFIX=/usr/local/avr-4.6.1

welcher dann in PATH landet

zu dem "prefix" bei configure:

> ../gcc-4.6.1/configure  --target=avr --prefix=/usr/local/avr

Das kann nicht klappen.

Ergänzend zu dem was Johann schon geschrieben hat: Ich verwende einen 
separaten UNIX-User zum kompilieren, und der prefix zeigt auf ein 
Verzeichnis in dessen /home-Verzeichnis. Auf das Gerangel in /usr/local/ 
verzichte ich. Am Ende den globalen PATH auf das Verzeichnis, und gut 
ist.

Roland H. schrieb:

[...]
> Ergänzend zu dem was Johann schon geschrieben hat: Ich verwende einen
> separaten UNIX-User zum kompilieren, und der prefix zeigt auf ein
> Verzeichnis in dessen /home-Verzeichnis. Auf das Gerangel in /usr/local/
> verzichte ich. Am Ende den globalen PATH auf das Verzeichnis, und gut
> ist.

Kannst du mir mal den konkreten Vorteil nennen den 
/home/ccuser/avr-4.6.1 gegenüber /usr/local/avr-4.6.1 haben soll?
Uhu hat doch extra eine eigene Hierarchie in /usr/local angelegt. Das 
bleibt doch selbst mit zwei Händen voll eigencompilaten noch 
übersichtlich.

Gruß
f

Uhu Uhuhu schrieb:

> Was kann das sein?

http://lists.nongnu.org/archive/html/avr-gcc-list/...

Eine GCC-Installation sieht forgendermassen aus:
Beitrag "Re: Eclipse: was bedeutet diese Fehlermeldung?"

Jetze installiere einmal nach /usr/local/avr und einmal nach /usr/local 
wo nicht unwahrscheinlich bereits eine Installation vorhanden ist 
(/usr/local der default-Prefix)

Klamüsere dann die beiden Insallationen auseinander! Es gibt eben Pfade, 
die man nicht verwenden sollte wie /usr/local/lib, /usr/local/bin, 
/usr/local/gcc oder eben /usr/local/avr.

> Uhu hat doch extra eine eigene Hierarchie in /usr/local angelegt. Das

Trotz besseren Wissens, denn Herrn/Frau Uhu wurde bereits davon 
abgeraten:

Beitrag "Re: Eclipse: was bedeutet diese Fehlermeldung?"

Auch wenn die oben beschriebenen Probleme wahrscheinlich eine andere 
Ursache haben, z.B. daß die avr-binutils nicht gefunden werden und der 
"normale" gas zum Assemblieren hergenommen wird.

Frank Lorenzen schrieb:
> Kannst du mir mal den konkreten Vorteil nennen den
> /home/ccuser/avr-4.6.1 gegenüber /usr/local/avr-4.6.1 haben soll?
> Uhu hat doch extra eine eigene Hierarchie in /usr/local angelegt. Das
> bleibt doch selbst mit zwei Händen voll eigencompilaten noch
> übersichtlich.

Ich kompiliere und installiere grundsätzlich (nicht nur bei gcc) als 
"non-root". Damit ist bei Experimenten (wie z. B. mit --prefix) 
sichergestellt, dass sich zwei "make install" gegenseitig die Dateien 
nicht überschreiben.

Spätestens bei "make install" benötigt man mehr als "normale" Rechte, um 
/usr/local/ zu beschreiben. Wozu der Ärger? Noch später, wenn es bei 
zwei Händen Eigenkompilaten zu Updates kommt, macht das keinen Spaß 
mehr.

Unabhängig davon: Wenn ich es löschen will, dann genügt es, diese User 
und deren Home-Verzeichnisse zu löschen. Ebenso ist es relativ einfach, 
diesen User und sein Home-Verzeichnis auf ein anderes System zu 
übertragen.

Der "richtige" Weg wäre natürlich, sich echte (Debian/RPM)-Pakete zu 
bauen. Der separate User ist ein Kompromiss, er dient zur Abschottung.

Johann L. schrieb:
> Trotz besseren Wissens, denn Herrn/Frau Uhu wurde bereits davon
> abgeraten:
>
> Beitrag "Re: Eclipse: was bedeutet diese Fehlermeldung?"

Ich sehe gerade in jenem Thread, dass auch noch ein Versuch mit /opt 
gemacht wurde ... die gleiche Problematik in grün.

Johann L. schrieb:
> 1) --prefix=/usr/local/avr
>    SOWAS MACHT MAN NICHT

Quelle: 
http://www.rn-wissen.de/index.php/Avr-gcc_und_avrd...
Und der ist nicht der Einzige, der das empfielt...

Ich hab den prefix aber immer Versionsabhängig gemacht, um irgendwelchem 
Versionskuddelmuddel aus dem Weg zu gehen. (Das prefix-Verzeichnis 
sollte vor dem make install mindestens leer sein, wenn es existiert.)

>    Es sei denn man legt es auf Ärger an, zB falls es bereits eine
>    Installation mit dem default(!) prefix /use/local gibt.

Eine Installation über den Linux Package Manager gibts nicht auf der 
Maschine - um derlei Probleme zu umgehen.

Es existiert unter /usr/local/avr-4.6.0 ein Compiler.

Gehe ich recht in der Annahme, daß prefix das Compilat auf den Pfad 
konfiguriert, auf den es mit make install erst hingehievt wird, aber auf 
die aktuelle Generierungsumgebung (die für den avr-gcc) keine 
Auswirkungen hat?

> 2) Welchen Assembler verwendest du?

GNU assembler version 2.20.1 (x86_64-linux-gnu) using BFD version (GNU 
Binutils for Ubuntu) 2.20.1-system.20100303

> 3) gmp, mpfr, mpc hast du

Ja.

> 4) Welchen Wert hat $CC?

Keinen. Compiliert wird mit gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) 
und nicht unter root.

> 5) Bitte das richtige config.log anhängen.

Siehe Anhang.

Johann L. schrieb:
> Jetze installiere einmal nach /usr/local/avr und einmal nach /usr/local
> wo nicht unwahrscheinlich bereits eine Installation vorhanden ist
> (/usr/local der default-Prefix)

Ich komme nicht bis zum make install - deswegen ist das alles erstmal 
nicht von Belang.


Roland H. schrieb:
> Wie passt
>
>> export PREFIX=/usr/local/avr-4.6.1
>
> welcher dann in PATH landet
>
> zu dem "prefix" bei configure:
>
>> ../gcc-4.6.1/configure  --target=avr --prefix=/usr/local/avr
>
> Das kann nicht klappen.

Richtig. Da ist ein Fehler in meinem Kommando-Zitat, den ich bei der 
Generierung ausgelassen habe. Nur hilft das auch nix gegen den 
make-Fehler, an dem ich scheitere.

Was die Klimmzüge mit einem Extra-User für einen entscheidenden Vorteil 
haben sollen, verstehe ich nicht.


Frank Lorenzen schrieb:
> Kannst du mir mal den konkreten Vorteil nennen den
> /home/ccuser/avr-4.6.1 gegenüber /usr/local/avr-4.6.1 haben soll?

Ich würde mal behaupten, es gibt keinen, wenn man sich nicht in seinen 
prefixen verheddert.


Jörg Wunsch schrieb:
>> Was kann das sein?
>
> http://lists.nongnu.org/archive/html/avr-gcc-list/...

Was er mit den Symlinks bezweckt, verstehe ich nicht. Wenn ich ABI=32 
zum configure zufüge, ändert sich nichts.

Dein Problem entsteht wenn du am Environment rumbastelst. Exportiere 
kein $PREFIX und fummel nicht an $PATH herum. Übergebe den Prefix nur 
dem configure-Script.
Mit einem neuen, leeren BUILDDIR und rückgesetztem $PREFIX/$PATH sollte 
er durchbauen.

BTW: Seit ein paar Tagen ist auch 4.6.2 da.


Gruß
f

Frank Lorenzen schrieb:
> Mit einem neuen, leeren BUILDDIR und rückgesetztem $PREFIX/$PATH sollte
> er durchbauen.

Leider nicht. Es ändert sich nichts.

Ich habe ein neues Terminal geöffnet und darin folgende Befehle 
ausgeführt:

PREFIX=/usr/local/avr-4.6.1/
SOURCE=/tmp/gcc-4.6.1
$SOURCE/configure --target=avr --prefix=$PREFIX --disable-nls --enable-languages=c --disable-libssp
make

config.log unterscheidet sich nur durch die jetzt fehlenden 
PATH-Komponenten.

Uhu Uhuhu schrieb:

> Ich habe ein neues Terminal geöffnet und darin folgende Befehle
> ausgeführt:
> [pre]
> PREFIX=/usr/local/avr-4.6.1/
> SOURCE=/tmp/gcc-4.6.1

Aber die passenden binutils hast du mit dem gleichen Präfix darin
zuvor gebaut und installiert, ja?

mpfr, gmp etc. hast du in ausreichend neuer Version in deinem
Basissystem?

Uhu Uhuhu schrieb:
> config.log unterscheidet sich nur durch die jetzt fehlenden
> PATH-Komponenten.

Es gilt immer noch das in
Beitrag "Re: Problem beim Compilieren von gcc 4.6.1"
gesagte:

5) Bitte das richtige config.log anhängen.

Da es sich im libgcc handelt, wird vermutlich nicht der richtige 
Assembler verwendet. Und es dürfte klar sein, daß der Host-Assembler 
nicht Assembler-Code für AVR assemblieren kann.

Wenn, wie Jörg gesagt hat, die Binutils mir dem gleichen Präfix gebaut 
und dort installiert wurden, wird der richtige Assembler genommen.

Ober der Assembler/Linker muss im Pfad sein. Das siehst du aber alles in 
den Ausgaben von configure welche Tools hergenommen werden.

Uhu Uhuhu schrieb:
> Frank Lorenzen schrieb:
>> Mit einem neuen, leeren BUILDDIR und rückgesetztem $PREFIX/$PATH sollte
>> er durchbauen.
>
> Leider nicht. Es ändert sich nichts.

Uhu ich muß mich entschuldigen, da hab ich heut nachmittag Unsinn 
geschrieben.
Ich habe mich da beim Nachstellen deines Problems selbst in die Irre 
leiten lassen.


Gruß
f

hp-freund schrieb:

> Ich fürchte Punkt 3 ist das ganze Problem gewesen...

Wie Johann schon schrieb, wenn --prefix für avr-binutils und
avr-gcc übereinstimmen (und dann zweckmäßig später auch für avr-libc),
dann ist dies nicht einmal notwendig.  ${prefix}/bin wird automatisch
nach den Binaries durchsucht.

Nach Installation ist es allerdings praktisch, die neuen Tools im Pfad 
zu haben und nicht immer den absoluten Pfad angeben zu müssen.

Wenn man nicht will, daß der neue avr-gcc den alten "überdeckt", kann 
man den Pfad auch hinten in PATH anhängen und den Compiler 
mit avr-gcc-4.6.2 aufrufen (falls nur ein avr-gcc-4.6.2 vorhanden ist).

Zudem muss beim Build der avr-libc der gewünschte avr-gcc gefunden 
werden (und der einzig sinnvolle ist der momentan erzeugte) oder man 
muss avr-libc beim configure ein

CC="/das/ist/mein/lieblings-avr-gcc"

mitgeben.

Oder sucht das avr-libc configure in prefix bevor es PATH auswertet?

Johann L. schrieb:
> Oder sucht das avr-libc configure in prefix bevor es PATH auswertet?

Hmm, müsste ich nachsehen.  Wäre zumindest ein nützliches Fietscher. ;)

Jörg Wunsch schrieb:
> Johann L. schrieb:
>> Oder sucht das avr-libc configure in prefix bevor es PATH auswertet?
>
> Hmm, müsste ich nachsehen.  Wäre zumindest ein nützliches Fietscher. ;)

Priorität-Wunschzettel:

1) CC
2) --prefix
3) PATH

Johann L. schrieb:

> Priorität-Wunschzettel:
>
> 1) CC
> 2) --prefix
> 3) PATH

1 und 3 sind schon (Standard-autoconf bzw. make-Verhalten), nur bei 2
bin ich mir nicht sicher.

Mach' mal bitte einen enhancement request bei avr-libc dafür auf,
als Erinnerung.  Heute und morgen werd' ich nicht dazu kommen.

Uhu, schau dir mal (im Buildverzeichnis) avr/libgcc/config.log an.
Steht da was, dass er ein shared object nicht finden konnte (ich
glaube, es war libmpc.so)?

Das war bei mir der Fall.  Abhilfe:

export LD_LIBRARY_PATH=${prefix}/lib

Danach läuft alles durch (stock GCC 4.6.2, gerade getestet).

Wahrscheinlich sollte man die GCC-Hilfsbibliotheken (gmp, mpc, mpfr)
besser gleich nur statisch bauen.

Jörg Wunsch schrieb:
> Wahrscheinlich sollte man die GCC-Hilfsbibliotheken (gmp, mpc, mpfr)
> besser gleich nur statisch bauen.

Ja, mit --disable-shared geht es dann auch so prima durch.  Man muss
natürlich vorher aus ${prefix}/lib die bereits früher einmal
compilierten shared libs rauswerfen.

hp-freund schrieb:
> Besteht das Original-Problem eigentlich noch?

Meine Ausführungen bezogen sich zumindest auf ebendieses.  Ich hatte
versucht, einen frisch runtergeladenen GCC 4.6.2 für den AVR zu
bauen, und war auch erst einmal über dieses "cannot compute suffix
of object files: cannot compile" gestolpert.

Beim Build des aktuellen avr-libc snapshot 2259 bekomme ich mit avr-gcc 
4.7.0:

avr-gcc -DHAVE_CONFIG_H -I. -I../../..  -I../../../common 
-I../../../include -I../../../include  -I../../../common 
-I../../../include -I../../../include -x assembler-with-cpp -Wa,-gstabs 
-mmcu=avr31 -D__COMPILING_AVR_LIBC__   -MT memcpy_PF.o -MD -MP -MF 
.deps/memcpy_PF.Tpo -c -o memcpy_PF.o ../../../libc/pmstring/memcpy_PF.S
../../../common/macros.inc: Assembler messages:
../../../common/macros.inc:362: Error: constant value required
make[5]: *** [memcpy_PF.o] Error 1
make[5]: Leaving directory `/local/gnu/build/avr-libc/avr/lib/avr31'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/local/gnu/build/avr-libc/avr/lib/avr31'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/local/gnu/build/avr-libc/avr/lib'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/local/gnu/build/avr-libc/avr'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/local/gnu/build/avr-libc'
make: *** [all] Error 2

Problem scheint eine fehlende Makro-Definition zu sein.

Seltsam, dass ich das mit GCC 4.6.2 nicht sehe.

Ist natürlich ohnehin zweifelhaft, warum er ein memcpy_PF.S
assemblieren will für -mmcu=avr31.  Die "PF"-Routinen haben nur bei
avr5 und darüber Sinn.

Jörg Wunsch schrieb:
> Ist natürlich ohnehin zweifelhaft, warum er ein memcpy_PF.S
> assemblieren will für -mmcu=avr31.  Die "PF"-Routinen haben nur bei
> avr5 und darüber Sinn.

Hmm, mit GCC 4.6.2 ergibt sich:

Disassembly of section .text:

00000000 <memcpy_PF>:
   0:   e4 2f           mov     r30, r20
   2:   f5 2f           mov     r31, r21
   4:   a8 2f           mov     r26, r24
   6:   b9 2f           mov     r27, r25
   8:   00 c0           rjmp    .+0             ; 0xa <memcpy_PF+0xa>
                        8: R_AVR_13_PCREL       .text+0x10
   a:   c8 95           lpm
   c:   31 96           adiw    r30, 0x01       ; 1
   e:   0d 92           st      X+, r0
  10:   21 50           subi    r18, 0x01       ; 1
  12:   30 40           sbci    r19, 0x00       ; 0
  14:   00 f4           brcc    .+0             ; 0x16 <memcpy_PF+0x16>
                        14: R_AVR_7_PCREL       .text+0xa
  16:   08 95           ret

d. h. es wird ganz normal ein LPM generiert.  Das heißt, dass in
common/macros.inc das BIG_CODE definiert sein muss bei GCC 4.7.0.
Das wiederum hängt ab von FLASHEND > 0x10000.

Ist irgendwie alles sehr seltensam.  FLASHEND hat im Zusammenhang
mit einer generischen Bibliothek (wie avr31) keinen wirklichen
Sinn.  avr31 wiederum ist nur für den steinalten ATmega103 gedacht
(der wirklich ein FLASHEND > 0x10000 hat) und den Exoten
AT43USB320, den man wahrscheinlich nicht mehr in freier Wildbahn
irgendwo finden wird ...

Wir sollten das auf der avr-libc-dev-Liste diskutieren, vielleicht
auch gleich einen Bugreport einreichen.

Jörg Wunsch schrieb:
> vielleicht
> auch gleich einen Bugreport einreichen.

Danke für den anderen Report!  (#34719)

avr-gcc hat folgende built-in Makros mit deren Hilfe das 
parametrisierbar ist:

__AVR_HAVE_RAMPZ__
__AVR_HAVE_ELPM__
__AVR_HAVE_ELPMX__
__AVR_HAVE_LPMX__

Uhu Uhuhu schrieb:
> Was die Klimmzüge mit einem Extra-User für einen entscheidenden Vorteil
> haben sollen, verstehe ich nicht.

Die einfache Möglichkeit, rückstandsfrei die Überbleibsel eines 
fehlgeschlagenen "make install" zu entfernen.

Welcher Klimmzug? adduser x, ssh x@localhost, fertig.

hp-freund schrieb:
> Nachtrag: /daten/programme gehört einem normalen Benutzer. make install
> kann somit von diesem ausgeführt werden (keine root Rechte)

Zumindest einer hat die Idee aufgegriffen :-) So sieht's bei mir aus:

$ ls /home/*/data/*-toolchain/bin/*-gcc
/home/arm/data/arm-toolchain/bin/arm-elf-gcc
/home/msp430/data/msp430-toolchain/bin/msp430-gcc
/home/renesas/data/renesas-toolchain/bin/m32c-elf-gcc

(dazu noch avr-gcc normal via Debian-Paket)

Johann L. schrieb:
> Wenn man nicht will, daß der neue avr-gcc den alten "überdeckt", kann
> man den Pfad auch hinten in PATH anhängen und den Compiler
> mit avr-gcc-4.6.2 aufrufen (falls nur ein avr-gcc-4.6.2 vorhanden ist).

Das hatte ich gestern zufällig versucht, da ich GCC 4.6.2 für AVR mit 
Deinem "C++ warning: only initialized variables can be placed into 
program memory area" - Patch gerne einsetzen würde (vielen Dank!).
Wie verhält es sich mit "nm", "size" et. al. ?