www.mikrocontroller.net

Forum: GCC Problem beim Compilieren von gcc 4.6.1


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Uhu Uhuhu (uhu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland H. (batchman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland H. (batchman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Frank Lorenzen (florenzen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab es auch mal probiert. Nach

http://www.rn-wissen.de/index.php/Avr-gcc_und_avrd...

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

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: /daten/programme gehört einem normalen Benutzer. make install 
kann somit von diesem ausgeführt werden (keine root Rechte)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Wie Johann schon schrieb, wenn --prefix für avr-binutils und
> avr-gcc übereinstimmen ...

Hast Recht. Frisch getestet :-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;)

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besteht das Original-Problem eigentlich noch?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich auch :)

Ein weiteres Problem sehe ich in der in dieser Version nicht vorhandenen 
atxmega Unterstützung falls diese gewünscht ist.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> vielleicht
> auch gleich einen Bugreport einreichen.

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

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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__

Autor: Roland H. (batchman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ?

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du noch /opt statt /daten/programme verwendest, ist das sogar 
LSB-konform. Genau dafür gibt's das nämlich.

Autor: hp-freund (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.