------- Comment #25 from WISD00M at GMX dot NET 2006-09-13 05:02 -------
Just for your info: I just tried to compile the two previous official releases
on the same machine to troubleshoot this issue further (using no configure/make
flags WHATSOEVER, building in a separate build directory in both cases):
gcc 4.0.3 (347231730fb44b609b69226c3e432d80 gcc-core-4.0.3.tar.bz2) and
gcc 4.1.0 (15efa164579c7cf4a48859ee87d2a1fa gcc-core-4.1.0.tar.bz2)
(both obtained from gcc mirrors)
While I did succeed compiling gcc 4.0.3 on the same machine (after however
applying the patch mentioned in bug 27023 due to a too recent GNU make
version), compiling gcc 4.1.0 DID indeed cancel at the same point as the two
later releases did:
/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD/./gcc/xgcc
-B/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -isystem
/usr/local/i686-pc-linux-gnu/sys-include -O2 -O2 -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -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 -g0
-finhibit-size-directive -fno-inline-functions -fno-exceptions
-fno-zero-initialized-in-bss -fno-unit-at-a-time -fno-omit-frame-pointer \
-c ../../gcc-4.1.0/gcc/crtstuff.c -DCRT_BEGIN \
-o crtbegin.o
../../gcc-4.1.0/gcc/crtstuff.c:1: sorry, unimplemented: 64-bit mode not
compiled in
make[2]: *** [crtbegin.o] Error 1
make[2]: Leaving directory `/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/root/tmp/gcc-4.1.0/gcc-4.1.0-BUILD'
make: *** [all] Error 2
So, the cause for this really seems to have crept in somewhere in between 4.0.3
and 4.1.0, thus I ask anybody in the know: were there any additional
dependencies (or default assumptions) introduced in either the underlying build
system or alternatively the xgcc/cc1 files during that time line that could
explain the behaviour I'm seeing here?
Thanks for any further pointers
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29049
