avr-gcc-4.1

[Thomas W. (Gast)]

Hallo,
kann es sein, dass GCC 4.1 sich nicht für target=avr bauen lässt? Das
geht bei mir weder under Windows (MinGW) noch unter Linux. GCC 4.0.3
geht unter Linux problemlos, aber unter Windows gibts die gleiche
Fehlermedlung wie bei 4.1:

In file included from ../../gcc/libgcc2.c:43:
./tm.h:4:29: error: config/avr/avr.h: No such file or directory
./tm.h:5:28: error: config/dbxelf.h: No such file or directory
./tm.h:6:31: error: config/tm-dwarf2.h: No such file or directory
./tm.h:7:23: error: defaults.h: No such file or directory

diese Dateien sind aber definitiv vorhanden.
Die Fehlermeldung von 4.1 unter Linux hab ich jetzt nicht mehr parat,
ist aber auch nicht so wichtig. Hat jemand ne Idee?

Gruß, Thomas

[Jörg W. (dl8dtl) (Moderator)]

Hmm, es gibt einen Bugreport bei GCC, der besagt, dass es sich
nicht bauen ließe, aber die Fehlermeldungen waren andere.

Ich habe es vorhin gerade unter FreeBSD probiert, da tat alles.

Aber wart' mal, das da sieht aus, als hätte dein configure
irgendeine Variable nicht ausgefüllt.  Lass mich raten, irgendwo
in der Kommandozeile steht dann ein

... -I -Ifoo/bar ...

drin.  Das Makefile hat dazu

... -I${irgendwas} -I${irgendwasanderes} ...

und der Makro "irgendwas" ist leer.  Dann nimmt das erste -I
den String -Ifoo/bar als Argument (Verzeichnis, in dem die
Include-Dateien zu suchen sind), aber eigentlich hätte das so
aussehen sollen:

... -I. -Ifoo/bar ...

damit die genannten Includes auch gefunden werden.

Warum das aber so rausgekommen ist, musst du mal selbst
recherchieren.  Methode für Faule: man editiert das (generierte)
Makefile selbst. ;-)

[Thomas W. (Gast)]

Hallo Jörg,
danke für deine Mühe, hier noch die Fehlermeldungen unter Linux:

/home/thomas/gcc-4.1.0/obj-avr/./gcc/xgcc
-B/home/thomas/gcc-4.1.0/obj-avr/./gcc/
-B/home/thomas/local/avr/avr/bin/ -B/home/thomas/local/avr/avr/lib/
-isystem /home/thomas/local/avr/avr/include -isystem
/home/thomas/local/avr/avr/sys-include -O2  -O2 -g -O2   -DIN_GCC
-DCROSS_COMPILE   -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include
-DDF=SF -Dinhibit_libc -mcall-prologues -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc
-I../../gcc/. -I../../gcc/../include -I../../gcc/../libcpp/include
-DL_fixunssfsi -c ../../gcc/libgcc2.c -o libgcc/./_fixunssfsi.o
../../gcc/libgcc2.c: In function '__fixunssfsi':
../../gcc/libgcc2.c:1499: internal compiler error: in
compute_frame_pointer_to_cfa_displacement, at dwarf2out.c:10445
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html>; for instructions.
make[3]: *** [libgcc/./_fixunssfsi.o] Error 1
make[3]: Leaving directory `/home/thomas/gcc-4.1.0/obj-avr/gcc'
make[2]: *** [stmp-multilib] Error 2
make[2]: Leaving directory `/home/thomas/gcc-4.1.0/obj-avr/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/thomas/gcc-4.1.0/obj-avr'
make: *** [all] Error 2

So, werd dann nochmal Windows booten und deinen Vermutungen
nachgehen...

[Jörg W. (dl8dtl) (Moderator)]

Ja, das ist das, wofür es schon einen Bugreport gibt.

Seltensamerweise habe ich unter FreeBSD kein Problem damit.

gmake[3]: Entering directory `/tmp/avr-gcc/work/compile/gcc'
/tmp/avr-gcc/work/compile/./gcc/xgcc -B/tmp/avr-gcc/work/compile/./gcc/
-B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem
/usr/local/avr/include -isystem /usr/local/avr/sys-include -O2  -O2 -g
-O2   -DIN_GCC -DCROSS_COMPILE   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include  -DDF=SF -Dinhibit_libc -mcall-prologues -g
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I.
-I../../gcc-4.1.0/gcc -I../../gcc-4.1.0/gcc/.
-I../../gcc-4.1.0/gcc/../include
-I../../gcc-4.1.0/gcc/../libcpp/include  -DL_fixunssfsi -c
../../gcc-4.1.0/gcc/libgcc2.c -o libgcc/./_fixunssfsi.o
rm -f ./libgcc.a
avr-ar  rc ./libgcc.a libgcc/./_mulqi3.o ...

Hmm, sag mal, hast du den GCC aus einem separaten Verzeichnis heraus
compiliert (das "compile" in meinem Fall)?  Das Compilieren direkt
aus
dem GCC-Basisverzeichnis ist ausdrücklich nicht unterstützt.

Ich habe:

. GCC mit tar ausgepackt
. daneben ein Verzeichnis "compile" aufgemacht
. cd compile
. ../gcc-4.1.0/configure --target=avr --disable-nls --disable-libssp
. gmake

(gmake heißt das GNU make bei mir.)

[Thomas W. (Gast)]

Da ist tatsächlich ein -I ohne Argument:

make[2]: Entering directory `/home/thomas/gcc-4.0.3/obj-avr/gcc'
/home/thomas/gcc-4.0.3/obj-avr/gcc/xgcc
-B/home/thomas/gcc-4.0.3/obj-avr/gcc/ -B /usr/local/avr/avr/bin/
-B/usr/local/avr/avr/lib/ -isystem /usr/local/avr/avr/in clude -isystem
/usr/local/avr/avr/sys-include -O2  -DIN_GCC -DCROSS_COMPILE   -W  -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-defi nition  -isystem ./include  -DDF=SF -Dinhibit_libc
-mcall-prologues -g  -DIN_LIB GCC2 -D__GCC_FLOAT_NOT_NEEDED
-Dinhibit_libc -I. -I -I../../gcc -I../../gcc/ -I. ./../gcc/../include
-I../../gcc/../libcpp/include  -DL_muldi3 -c ../../gcc/libgc c2.c -o
libgcc/./_muldi3.o

Direkt darauf folgt dann obige Fehlermeldung. Im Makefile steht
folgendes:

tm_file_list= $(srcdir)/config/avr/avr.h $(srcdir)/config/dbxelf.h
$(srcdir)/config/tm-dwarf2.h $(srcdir)/defaults.h
tm_include_list= config/avr/avr.h config/dbxelf.h config/tm-dwarf2.h
defaults.h
tm_defines=

Ich hab mich genau an die Anleitung der avrlibc gehalten, also alles
aus dem Unterordner obj-avr gestartet:
..configure --prefix=$PREFIX --target=avr -enable-languages=c,c++
--disable-nls --with-dwarf2
make
Hat mit früheren Versionen auch so funktioniert.

So, Feierabend jetzt, das ist mir alles zu kryptisch so spät am
Abend...

[Thomas W. (Gast)]

Das mit den tm_include_list ist wol nicht so hilfreich, dies hier
scheint mir Interessanter:

# Specify the directories to be searched for header files.
# Both . and srcdir are used, in that order,
# so that *config.h will be found in the compilation
# subdirectory rather than in the source directory.
# -I$(@D) and -I$(srcdir)/$(@D) cause the subdirectory of the file
# currently being compiled, in both source trees, to be examined as
well.
# libintl.h will be found in ../intl if we are using the included
libintl.
INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
     -I$(srcdir)/../include  \
     $(CPPINC) $(GMPINC)

$(@D) scheint leer zu sein, da soll anscheinend ein "." rein, hab das
grad mal per Hand im Makefile geändert...

...und funktioniert!
Aber wiso setzen die den Punkt in ein Makro, wiso geht das unter Linux
aber unter MSYS nicht? Und wie gehts jetzt weiter? Bugreport ans MinGW
Team?
Das war jetzt übrigens alles GCC-4.0.3, werd morgen mal schaun, ob sich
4.1 unter MinGW kompilieren lässt, der ist ja vorher an dem gleichen
Fehler gescheitert...

So, jetzt aber wirklich:
Gute Nacht!

[Thomas W. (Gast)]

Mit den configrue Optionen aus dem avrlibc-manual bekomm ich unter
Windows genau die gleiche Fehlermeldung wie unter Linux, mit deinen
configure Optionen geht es! Unter Linux hab ichs zwar noch nicht
getestet, wird aber da wol auch klappen, denk ich.

Was ist denn libssp? Ist das dieser neue Buffer-Overflow Schutz? Es lag
aber eher an "--with-dwarf2", in dem Error-Output steht ja auch was
von:
internal compiler error: in compute_frame_pointer_to_cfa_displacement,
at dwarf2out.c:10445

[Birger* (Gast)]

Hi, bau auch grad mal wieder ne neue Toolchain. Aber so ganz habe ich
das mit dem Tipp noch nicht gecheckt. Bislang habe ich immer
compiliert, dann -I$(@D) aus dem makefile entfernt und nochmal
compiliert. Reicht auch die weitere Option --disable-libssp , um das
Problem zu lösen???

[Jörg W. (dl8dtl) (Moderator)]

> Was ist denn libssp? Ist das dieser neue Buffer-Overflow Schutz?

So las es sich zumindest, ja.  Der braucht aber einiges von der
(Unix-)Standardbibliothek, das der AVR einfach nicht hat.

> Es lag aber eher an "--with-dwarf2", in dem Error-Output steht ja
> auch was von:

Ach ja, na klar.  Das ist der Unterschied...

Das ist natürlich dann nicht so toll, vor allem nicht für die
AVR-Studio-Nutzer.  Es wird wohl Zeit, dass sich mal jemand die
DWARF-2-Generierung für den AVR ansieht, bislang hat die mehr zufällig
funktioniert, weil DWARF-2 für die mainstream targets des GCC
aufgebaut worden ist.

Ich sehe nur im Moment keinen der AVR-GCC-Hacker, der irgendwie freie
Ressourcen hätte, sich um sowas zu kümmern. :(

> -I$(@D)

Hmm, das scheint ein Bug in der make-Portierung zu sein dann.  Laut
GNU Make Manual evaluiert $(@D) zu:

The directory part of the file name of the target, with the
trailing slash removed.  If the value of `$@' is `dir/foo.o' then
`$(@D)' is `dir'.  This value is `.' if `$@' does not contain a
slash.

d. h. es sollte nie leer sein.

[Jonny (Gast)]

Hallo in die AVR-GCC Gemeinde,

ich möchte gerade ein neues AVR Projekt starten. Da ich auf Solaris 
10/11 und Mac OS arbeite, benötige ich einen C-Compiler. Ich reiße kurz 
ab, was ich dazu benötige und wie ich mir den avr-gcc gebaut habe.
Es wird benötigt:
1.binutils-2.17.tar.bz2  von 
http://www.icewalkers.com/download/binutils/1276/dls/
2.gcc-4.2.1.tar.bz2  von ftp://ftp.gnu.org/gnu/gcc/gcc-4.2.1/
3.avr-libc-1.4.6.tar.bz2  von http://www.nongnu.org/avr-libc/

Vorbereitung :
mkdir /usr/local/avr ; chown jonny /usr/local/avr  ( ich benutzt den 
User jonny )
mkdir /home/jonny/build_avr
es werden die Archive binutils-2.17.tar.bz2, gcc-4.2.1.tar.bz2 und 
avr-libc-1.4.6.tar.bz2 ausgepackt.
Beispiel jonny@powerbook:~/build_avr $ bzcat 
../download/gcc-4.2.1.tar.bz2 | gtar xvf -
PATH setzen: export PATH=$PATH:/usr/local/avr/bin ; .profile bzw. 
.bash_profile nicht vergessen, damit der PATH morgen auch noch vorhandes 
ist ;)

Bau der binutils:
cd binutils-2.17
./configure --target=avr –prefix=/usr/local/avr
gmake
gmake install
cd ..

Bau des gcc:
cd gcc-4.2.1
./configure --target=avr --prefix=/usr/local/avr 
--enable-languages=c,c++ --disable-nls --disable-libssp –with-dwarf2
gmake
gmake install

Bau der avr-libs:
cd avr-libc-1.4.6
./configure --prefix=/usr/local/avr-421 --target=avr 
--enable-languages=c –host=avr
gmake
gmake install


Viel Spaß damit!