TJ22 wrote :
I am trying to build GCC 3.0 on my suse 10.1 machine that has gcc 4.1.0. I
need it to check backwards compatibility with some readers I have written.
Is is crashing on me:
gcc -I../../gcc-3.0/gcc/cp -I../../gcc-3.0/gcc/config
-I../../gcc-3.0/gcc/../include ../../gcc-3.0/gcc/cp/decl.c -o cp/decl.o
../../gcc-3.0/gcc/cp/decl.c: In function ‘push_binding_level’:
../../gcc-3.0/gcc/cp/decl.c:528: error: invalid lvalue in assignment
Generally it should work to just take some older "native" GCC and
the native glibc it uses from some older "compatible" Linux distro,
in this case SuSE, and install it into your newer Linux distro... But
because the Linux users haven't demanded this kind of thing to
succeed easily, then it doesn't succeed easily :-(
But if you look with the well-known 'gcc -print-search-dirs' and the
'cpp -v' commands where that old GCC will search its subprograms
(cc1, as, collect2, ld), its target libraries and headers, you will see
that directories like the '$tooldir', the '$prefix/$target', will be
searched before those "native" places, '/lib', '/usr/lib' and
'/usr/include' !
Like searching the libs in my "native" gcc-3.3.4 in SuSE 9.2 :
------------------ clip -------------------------
libraries: =
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/:
/usr/lib/gcc/i586-suse-linux/3.3.4/:
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../../i586-suse-linux/lib/i586-suse-linux/3.3.4/:
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../../i586-suse-linux/lib/:
<--- !!
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../i586-suse-linux/3.3.4/:
/usr/lib/gcc-lib/i586-suse-linux/3.3.4/../../../:
/lib/i586-suse-linux/3.3.4/: <-- !!
/lib/: <--- !!
/usr/lib/i586-suse-linux/3.3.4/: <-- !!
/usr/lib/ <--- !!
------------------ clip -------------------------
Extracting those old 'gcc' and 'cpp' driver binaries from some old GCC
RPMs and trying to run them (with these options), will easily tell if there
are any binary incompatibilities between these executables and the current
runtime libraries ('ld-linux.so.2', 'libc.so.6' etc.), seen with 'ldd'....
The directory searched as the 4th one, '/usr/lib/i586-suse-linux/lib'
could so sound being 'suitable' for putting those "alien" glibc parts
for an "alien" Linux target, but if the "$target" for the old GCC is
"just the same", here 'i586-suse-linux', also the existing native GCC
would search from it! So the second last and the 4th last with that
'$gcc-version' in them would be the best for installing stuff from the
older Linux glibc in that older Linux distro from where that older
GCC was taken! That there isn't any "Linux version" suffix in the
'$target' name like 'i586-suse-linux9.2' or 'i586-suse-linux10.1', is
really a weird choice! Is a "SuSE Linux 8.2" really the same as
"SuSE Linux 10.1" as the '$target' platform?
If you would think installing this SuSE 9.2 gcc-3.3.4 with its glibc-2.3.3
into your SuSE 10.1, putting first its '/lib' stuff into the
'/lib/i586-suse-linux/3.3.4' and its '/usr/lib' stuff into the
'/usr/lib/i586-suse-linux/3.3.4', from its 'glibc-2.3.3' install RPMs (first
unpacking these into some temporary directory!), plus putting its
'/usr/include' stuff into the
'/usr/lib/gcc-lib/i586-suse-linux/3.3.4/include',
could sound most sane... Then doing similar things with the GCC RPMs,
first unpacking them temporarily somewhere and then renaming its 'gcc',
'g++', 'cpp' etc. before moving them into their final places, so that they
wouldn't clash/owerwrite the existing gcc-4.1.1 ones... Using a '-3.3' or
a '-3.3.4' suffix in this case could be suggested...
The GCC RPMs will also have headers going to the
'/usr/lib/gcc-lib/i586-suse-linux/3.3.4/include', but the only one clashing
with the glibc ones already there should be the 'limits.h' :
------------------ clip -------------------------
kai@Dell:/usr/lib/gcc-lib/i586-suse-linux/3.3.4/include> l
total 164
drwxr-xr-x 2 root root 440 2006-07-05 19:20 ./
drwxr-xr-x 3 root root 408 2006-07-05 19:20 ../
-rw-r--r-- 1 root root 34616 2004-10-02 01:14 emmintrin.h
-rw-r--r-- 1 root root 5372 2004-10-02 01:14 float.h
-rw-r--r-- 1 root root 1440 2004-10-02 01:14 iso646.h
-rw-r--r-- 1 root root 3470 2004-10-02 01:14 limits.h <---- !!
-rw-r--r-- 1 root root 22293 2004-10-02 01:14 mmintrin.h
-rw-r--r-- 1 root root 3598 2004-10-02 01:14 pmmintrin.h
-rw-r--r-- 1 root root 750 2004-10-02 01:14 README
-rw-r--r-- 1 root root 4325 2004-10-02 01:14 stdarg.h
-rw-r--r-- 1 root root 1612 2004-10-02 01:14 stdbool.h
-rw-r--r-- 1 root root 12695 2004-10-02 01:14 stddef.h
-rw-r--r-- 1 root root 330 2004-10-02 01:14 syslimits.h <--- !!
-rw-r--r-- 1 root root 9299 2004-10-02 01:14 unwind.h
-rw-r--r-- 1 root root 139 2004-10-02 01:14 varargs.h
-rw-r--r-- 1 root root 31009 2004-10-02 01:14 xmmintrin.h
------------------ clip -------------------------
The GCC's own 'limits.h' #include's the 'syslimits.h', which then
normally #include_next's the glibc's own 'limits.h' :
------------------ clip -------------------------
/* syslimits.h stands for the system's own limits.h file.
If we can use it ok unmodified, then we install this text.
If fixincludes fixes it, then the fixed version is installed
instead of this text. */
#define _GCC_NEXT_LIMITS_H /* tell gcc's limits.h to recurse */
#include_next <limits.h>
#undef _GCC_NEXT_LIMITS_H
------------------ clip -------------------------
So just overwriting the earlier 'limits.h' from the glibc doesn't work...
The GCC's 'syslimits.h' must be replaced with the glibc's 'limits.h' by
'mv limits.h syslimits.h' in the install directory, and by removing the
GCC's 'syslimits.h' before moving the GCC stuff there from its temporary
places....
Ok, the idea was told here... But as you saw this isn't very well thought
out by the GCC developers and therefore isn't easy in any way :-(
The "right" solution would be to use a real crosscompiler, for instance
a gcc-3.3.4 targeted to SuSE 9.2 and this running on many Linux hosts...
I myself use Red Hat 7.3 hosted (= made to run primarily on this host)
GCCs for those "other Linuces" plus for the "native Linux" target... But
getting these is only another "Catch 22" or "chicken and egg" problem :-(
Bootstraping "everything" with a suitable old native GCC with its old native
glibc is one solution... Another one is to ask someone who already has
a suitable "bootstrap tool", like a Red Hat 7.3 hosted crosscompiler
producing code for SuSE 8.2, to send that... A third one could to trust the
gcc-4.1.1 being capable to produce gcc-4.0.3, then this capable to produce
gcc-3.4.6, then this being capable to produce gcc-3.3.6 and so on... But
all these should use the existing glibc in SuSE 10.1 ! Whether the gcc-3.0
would work with the glibc in SuSE 10.1, is then something totally unclear...
So handling GCC and glibc as "paired soldiers", "paired cops" etc. would
the most safe solution... The binutils should be more "generic", so no talk
about them here...
I myself haven't tried anything what I described here, the fact and an old
saying is "Those who know how to do that, they do that... Those who don't
know how to do that, they can only give advices for how to do that!" :-)
But in theory things should work this way... I don't believe those GCC
developers being too stupid to not enable adding another native GCC by
copying it into a system which already has a native GCC !
