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