gcc 2.95.3

Kai Ruottu karuottu@mbnet.fi
Thu Jan 12 10:12:00 GMT 2006

Daniel Alejandro Benavides Diaz wrote:

 > Hello all:
 > I'm trying to compile a virtual machine library (http://a386.nocrew.org)
 > under SuSE 9.3 (with gcc 3.3.5), but I got various errors. Searching the
 > cause, I found that gcc is more strict in these days, so I tried with
 >  the old know gcc 2.95.3, and then I could compile it and the a386.

Your logic seems to to work a little differently from mine... My logic is as

1. You have SuSE 9.3 with its gcc-3.3.5, its binaries linked against 
some glibc-2.3.x
    version (the provided C library) and it using the same glibc-2.3.x 
as its target C
    library during all compiles. Also the provided system binutils are used.

2. You could first think to add gcc-2.95.3 to the set, its binaries also 
linked against
     the same glibc-2.3.x system C library and it using this also as its 
target C library
     in all its compiles. The provided system binutils would be used 
also with this second
     (native) GCC

 But quite probably the step 2 would not work because there is no 
"forwards compatibility"
in GCC, GCCs still working with all the C libraries which will appear in 
the future and being
compiled with future GCCs...  But things usually work vice versa: GCCs 
working with the
earlier and already existing C libraries.  For instance one could still 
have a Red Hat 6.2
installation and on it the current gcc-3.3.6, gcc-3.4.5 and maybe even 
those gcc-4.x versions.

 The same thing could be true with the "too new" binutils...

 > In order to use gcc 2.95.3 I had to install binutils-2.12.

 But I cannot believe this claim... This far the binutils updates have 
not made anything to
not work any more in the x86 toolchains. On some other archs (MIPS I 
remember) maybe...
The gcc-2.95.3's I once produced have seemed to work with the updated 
binutils, newer
GCCs in the toolchains may have required updating the binutils but the 
updated binutils of
course should still work with the old installed GCCs...

 > As the Linux From Scratch project sugget I built it with make 

 If you forget all the bolshevistic ideas pushed to the Linux worlds: 
"All the Linuces, Unite!",
"Start Everything Again From Scratch, Forget All The Bad 
Corporatism/Capitalism!" (SuSEs,
Red Hats, Mandrake/Mandriva's, Debians, Gentoos, Ubuntus,...) etc., and 
think that these
not-compatible-with-each-others Linuces maybe are here to stay, that 
could be more near
the past and current reality...

 Or that it really is the aim that Linuces should not be binary 
compatible.  If they were, who
then would care to compile anything from its sources?  Why not only 
mimic the DOS/Windoze
world, where almost all apps are distributed only as binaries?  
Originally the demand for binary
compatability came from the Linux-using companies, they preferring 
binaries and not being
happy with the non-compatible (with each other) SuSEs, Red Hats and so 
on, but the LFS
idea seems to have just  the same goal: to make all Linuces mutually 
binary compatible and
then let people to distribute everything only as binaries.

 Building apps as static binaries ("code bloat") is one way to work 
around the current binary

 Another way is to produce "compatible inside the distribution" apps, 
here "SuSE compatible"

 The last SuSE I had, was the version "5.2" (using 'libc5'), before 
switching to Red Hat ("6.2"
then), so I really don't know about the SuSE-glibc-2.x versions and 
their "backwards compability".
Anyway in the Red Hat world there is that, all the on/for old RHL6.2 
made (text mode) apps
still working on the more uptodate? RHL ones ("8.0", "9").  But the RHL 
7.3 could be the
current "least common nominator" in the "Red Hat compatible" binaries. 
Maybe there is some
SuSE 7.x used as the equivalent to RHL 7.3 in the SuSE world....

 So, following my logic your task could be :

1. to find out what is this current "least common nominator" in the SuSE 
world (nobody any
    more or very few  using older SuSE system than that)

2. to produce a crosstoolchain for this, first hosted on your SuSE 9.3, 
compiled with gcc-3.3.5
   and its binaries linked against the system glibc-2.3.x, but when 
being ready, finally to be
   "self-hosted", ie. being "compiled and linked with itself", a "SuSE 
compatible  toolchain producing
   apps for all the SuSE compatible systems".  This could be the 
starting point for your "portable set
   of GCCs for SuSE" on the years to come after adding gcc-3.2.3, 3.3.6, 
3.4.5, 4.0.x, 4.1.x, 4.2.x
   etc. into the set... (The 3.0  and  3.1 GCC versions assumed being 
too unstable as production tools...)

 I myself have those recent RHL's (6.2 - 9) supported but finding older 
than the 9.x SuSE distros
(their glibcs etc. libraries) from the net seems to be hard, 
surprisingly they have all vanished... If
you haven't those old SuSE CDs anywhere, your task could be very 
hard.... But let's be optimistic.
The text-mode apps (binutils, GCCs,...) made for RHL 7.3 host have 
though seemed to work ok
on the SuSE 9.3 and 10.0 when tried...

 > *** glibc detected *** free(): invalid next size (fast): 0x0804b038 ***
 > Aborted
 > I do use free() function from malloc.h in that program, but with the 
newer gcc compiler it
 > works fine.

 The 'malloc.h' is only a header, the precompiled 'malloc()' function in 
the provided glibc-2.3.x
is the function being used with the gcc-2.95.3 compiled code....  Some 
clash here...  What I
remember is that just 'malloc()' was somehow changed between glibc-2.2.x 
and 2.3.x, old
64 MB PC:s not any more working with new Linuces using glibc-2.3.x in 
them, when trying
to compile something the same GCC version suddenly required tens of 
Megabytes when on
the old Linux never even near 32 Mbytes...  Two builds at the same time 
would put the PC
to use swapping and become horribly slow.  All the bullshit about Linux 
working also on older
PCs is just bullshit, a WinNT 4.0 works surely better on them than some 
Linux with similar
GUI possibilities.... Maybe OpenBSD, NetBSD but not any of the current 
Linux distros...
A Linux without Gnome/KDE should be compared only to DOS, SCO Unix 3.2, 
ISC Unix
3.2 or something from the early 90's...

 But for all sanity those old SuSE 7.x apps which were linked against 
its expected glibc-2.2.x,
with its 'malloc()' etc., should still work on SuSE 9.x...

> Then when I tried a c++ source file that is  compiled with the newer
> gcc, I got this with the old one:
> benavides@daniel:~/Desktop/banker/bankerAndrew> gcc -lstdc++ -o ban2 AlgorithmBanker.cpp

 Weird order... Never tried to differ from the "logical order" :

  gcc -o output input.cpp -lstdc++

ie. the libraries always told last...  But you never got to the link phase
so it is unclear if your weird order could have some influence.

> iostream.h: No such file or directory

The '$prefix/include/g++-v3' should be the place for the installed
gcc-2.95.3 C++ headers and my ones had this (old) 'iostream.h'...
So your situation is quite impossible, if you succeeded in the GCC
2.95.3 build with your current system glibc-2.3.x, and installed the
GCC, then you have this header and it will be found...

> I was thinking in install another glibc, as the LFS project stays,
> but could be a problem to my system?

 If you think replacing your current system glibc-2.3.x, that is really
insane thought !

 If you think producing a crosstoolchain for some earlier SuSE distro,
and use its system glibc in that toolchain, this is a very bright idea.
It is just the task I suggested !  But please forget all that LFS
bolshevism and fighting against the bad Linux companies, to sue them
if your "generic Linux targeted" crosstoolchain doesn't produce binaries
which don't work on your customized SuSE, and so on... Just build a
crosstoolchain to produce SuSE-compatible binaries with it, and maybe
after this another crosstoolchain to produce Red Hat compatible binaries
with it... "A Finn doesn't believe before he sees!", this is the attitude
here, what becomes the binary compatability between the Linux distros...

 Although having some positive experiences with those text-mode apps, it
is not anything weird to see the new FireFox 1.5, a GUI-mode app, to crash
on a two-three year old RHL 8.0, and expected to crash on a 4-5 year old
RHL 7.3 too. But its Windoze version running happily on almost 10 year old
WinNT 4.0...

More information about the Gcc-help mailing list