checking for suffix of object files... configure: error: in `/tmp/gcc/avr/libgcc':
21
configure: error: cannot compute suffix of object files: cannot compile
22
See `config.log' for more details.
23
make[1]: *** [configure-target-libgcc] Error 1
24
make[1]: Leaving directory `/tmp/gcc'
25
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:
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
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_avrdude_installieren#avr-gcc
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:
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
Ich hab es auch mal probiert. Nach
http://www.rn-wissen.de/index.php/Avr-gcc_und_avrdude_installieren
bin ich wie folgt vorgegangen:
1.Neueste Versionen heruntergeladen
binutils-2.21.1a
gcc-4.6.2
2. Wie im Beitrag binutils compiliert, zusätzlich im
configure .... --prefix=/daten/programme/avr-gcc-4.6.2
3. neuen Ordner in Pfad eintragen (Wichtig!):
export PATH=/daten/programme/avr-gcc-4.6.2/bin:$PATH
4. Wie im Beitrag gcc compiliert, zusätzlich im
configure .... --prefix=/daten/programme/avr-gcc-4.6.2
mpc,mpfr,gmp hatte ich schon im System, nichts weiter kopiert o.ä.
5. Freuen auf:
$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/daten/programme/avr-gcc-4.6.2/libexec/gcc/avr/4.6.2
/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --disable-nls
--enable-languages=c --disable-libssp
--prefix=/daten/programme/avr-gcc-4.6.2/
Thread model: single
gcc version 4.6.2 (GCC)
Ich fürchte Punkt 3 ist das ganze Problem gewesen...
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
1
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:
1
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.
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:
1
Disassembly of section .text:
2
3
00000000 <memcpy_PF>:
4
0: e4 2f mov r30, r20
5
2: f5 2f mov r31, r21
6
4: a8 2f mov r26, r24
7
6: b9 2f mov r27, r25
8
8: 00 c0 rjmp .+0 ; 0xa <memcpy_PF+0xa>
9
8: R_AVR_13_PCREL .text+0x10
10
a: c8 95 lpm
11
c: 31 96 adiw r30, 0x01 ; 1
12
e: 0d 92 st X+, r0
13
10: 21 50 subi r18, 0x01 ; 1
14
12: 30 40 sbci r19, 0x00 ; 0
15
14: 00 f4 brcc .+0 ; 0x16 <memcpy_PF+0x16>
16
14: R_AVR_7_PCREL .text+0xa
17
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.
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:
(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. ?
Ich habe inzwischen mehrere Versionen des gcc für verschiedene
Controller auf der Platte.
In jedem gcc Verzeichnis habe ich ein kleines script mit Inhalt in der
Form:
export PATH=$PATH:/daten/programme/avr-gcc/bin
Diese rufe ich so auf:
source /daten/programme/avr-gcc/avr.sh
Wenn ich den avr-gcc wieder loswerden will:
source /etc/profile
Für die anderen entsprechend. So kommen die compiler sich nicht in die
Quere da immer nur einer (und die zugehörigen Progs/Libs usw.) gefunden
wird...
Kann man machen.
Es ist aber so das /daten eine eigene grosse Partition ist. Wenn ich mal
mein System wieder neu aufsetze oder zur Sicherung hab ich alles
zusammen.
Da ich es sowieso nicht weiter verbreiten will, spielt das aber keine
Rolle.
Hauptsache es läuft :-)
Thread beobachten
Seitenaufteilung abschalten