This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc 2.95.3


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
follows:

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 LDFLAGS="-all-static"

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
uncompatabilities...


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


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...



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]