On Thursday, 2 August 2012 at 19:10:33 UTC, Johannes Pfau wrote:
Am Thu, 02 Aug 2012 20:15:47 +0200
schrieb "Stefan Frijters" <sfrijt...@gmail.com>:
Thank you for the pointers. I just got the results of my first
attempt (it failed). I'm getting the same error as reported by
Sönke Ludwig above, and after some googling it seems to be
related to
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648889 . I'm
now going to retry with 'env CFLAGS="-g -O2
-I/usr/include/arm-linux-gnueabihf"
LDFLAGS="-L/usr/lib/arm-linux-gnueabihf" ../configure [etc]'.
I put in the "-g -O2" because that is something the make
mentioned being there before. I guess I'll know if it worked
in the morning...
Cheers,
Stefan
I didn't know the debian multiarch changes also affect
non-multiarch
installations. Adding -I/usr/include/arm-linux-gnueabihf to
CFLAGS
probably works (your link also suggests adding
-B/usr/include/arm-linux-gnueabihf though). Adding -O2 -g
shouldn't be
necessary, the configure scripts should add it when appropriate.
Other solutions:
Patch your gcc sources with debian's multiarch patch (Not sure
if those
work for gcc 4.8):
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch.diff?view=markup
http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.7/debian/patches/gcc-multiarch-trunk.diff?view=markup
Use the official debian gcc sources (GCC 4.7) which should
include this patch:
sudo apt-get install gcc-4.7-source
installs the sources at /usr/src/gcc-4.7/gcc-4.7.1-dfsg.tar.xz
Thank you once more for the response. My new attempt as described
above failed as well, but for a different reason. However, it
seems I'm reinventing the wheel after all because after more
careful reading it seems I'm now running into the same problem as
Sönke Ludwig had earlier:
/home/pi/gcc-4.8-20120624/objdir/./gcc/xgcc
-B/home/pi/gcc-4.8-20120624/objdir/./gcc/
-B/opt/gdc/arm-linux-gnueabihf/bin/
-B/opt/gdc/arm-linux-gnueabihf/lib/ -isystem
/opt/gdc/arm-linux-gnueabihf/include -isystem
/opt/gdc/arm-linux-gnueabihf/sys-include -g -O2
-I/usr/include/arm-linux-gnueabihf -O2 -g -O2
-I/usr/include/arm-linux-gnueabihf -DIN_GCC -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include
-fPIC -fomit-frame-pointer -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector -fPIC -fomit-frame-pointer -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/.
-I../../../libgcc/../gcc -I../../../libgcc/../include
-DHAVE_CC_TLS -o _clear_cache.o -MT _clear_cache.o -MD -MP -MF
_clear_cache.dep -DL_clear_cache -c ../../../libgcc/libgcc2.c
In file included from ../.././gcc/tm.h:32:0,
from ../../../libgcc/libgcc2.c:31:
../../../libgcc/libgcc2.c: In function '__clear_cache':
../../../libgcc/../gcc/config/arm/linux-eabi.h:117:36: error:
'not_used' undeclared (first use in this function)
#define CLEAR_INSN_CACHE(BEG, END) not_used
^
../../../libgcc/libgcc2.c:2068:3: note: in expansion of macro
'CLEAR_INSN_CACHE'
CLEAR_INSN_CACHE (beg, end);
^
../../../libgcc/../gcc/config/arm/linux-eabi.h:117:36: note: each
undeclared identifier is reported only once for each function it
appears in
#define CLEAR_INSN_CACHE(BEG, END) not_used
^
../../../libgcc/libgcc2.c:2068:3: note: in expansion of macro
'CLEAR_INSN_CACHE'
CLEAR_INSN_CACHE (beg, end);
^
make[2]: *** [_clear_cache.o] Error 1
make[2]: Leaving directory
`/home/pi/gcc-4.8-20120624/objdir/arm-linux-gnueabihf/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/pi/gcc-4.8-20120624/objdir'
make: *** [all] Error 2
I took a brief look at the offending macro in linux-eabi.h and it
is prefaced by a comment:
/* Clear the instruction cache from `beg' to `end'. This is
implemented in lib1funcs.S, so ensure an error if this
definition
is used. */
#undef CLEAR_INSN_CACHE
#define CLEAR_INSN_CACHE(BEG, END) not_used
So it seems that this crash is at least 'by design'. I will try
once more and see if I can get the multiarch patch applied.
However, at this point I have to admit I don't quite know what
I'm doing anymore, so if this fails I think I'll stick with my
squeeze image for now - even though the hard float support is
something I will need later for a hobby project I'm working on.
Again, thank you for your support.
