By curiosity I have rebuild gcc3 from rawhide (gcc3-3.0.1-3.src.rpm) and I
have a strange feelings about it?
Why is it called 3.0.1 when most of the stuffs are stored under directories
Why some files are called 3.0.2-20010905 at some places?
I have the feeling that the Gcc3 provided here is nothing else but the CVS
version of Sept 5th 2001 and I think it is a bad idea to put it in rawhide.
Why not simply provide a clean and standard gcc 3.0.1. RedHat has suffered
enough with the "unofficial" gcc 2.96 story. I don't think there is any
need to play this game again.
Gcc3 is new, it will cause enough problem by itself (or in fact because of
the programs who will not compile with it anymore) without adding any
troubles by providing a CVS version
Yes, it is a patched CVS snapshot from 3.0 branch. It is called 3.0.1
because 3.0.2 was not released yet.
3.0 branch is in critical bugfixes only mode, so using the latest version
from that branch is almost always a good idea (unless testing proves
Also the patches are needed, e.g. SHF_MERGE stuff which really saves space
(be it in kernel or elsewhere) was only commited to CVS head since 3.0
was frozen, but we have tested this a lot (it is in 2.96-RH too).
The number of patches against 3.0.x will grow, not shrink.
I understand your point.
Well, be cautious with the names of the directories (3.0.2) and the version of
Gcc it refers too (3.0.1), it might cause some misunderstanding...
Any problem compiling the Linux kernel or important libraries with gcc3?
Will the next version of RedHat be based on gcc3?
Using 3.0.1 dirs would mean change the version string from:
gcc version 3.0.2 20010905 (Red Hat Linux 7.1 3.0.1-3)
gcc version 3.0.1 20010905 (Red Hat Linux 7.1 3.0.1-3)
which I think would mean even more confusion (since it would not be obvious
what CVS is it based on; the directories gcc uses are based on this string).
Concerning problems: don't build glibc with gcc3 unless you patch it up,
otherwise C libs are just inefficient (they bring in libgcc_s.so eventhough
they don't have to if glibc with gcc3 patch is used).
Building C++ libraries with g++3 means you have to either rebuild everything
C++ with g++3, or make sure the libs don't collide with 2.96-RH C++ libs
(stuff like KDE, Qt, Aspell, ...).
I think it should be clear what the next version of RHL will be based on
(you see /usr/bin/gcc3 in gcc3 package, not /usr/bin/gcc, right?).
Watch rawhide to see when we'll start using gcc3 as base compiler...
OK. Thanks for your explanations. I am not planning to rebuild everything by
myself. I was curious to know what were the problems linked to the release of
If I understood correctly what you said, there will be a RH7.2 based on gcc2.96
and later on a 8.0 based on gcc3... Am I right?... :)
Well, with little luck I might even see Mosix join the team then... :)
Thanks for your responses to my simple questions.
I wish you a nice day.