I'm more concerned about the problems that might arise simply because the 
packages in the distro were built with it. What problems that may occur, if 
one get's into the habbit of making binary incompatible packages at every 
distro release it kind of renders the whole idea of rpm useless. There will 
be rpm's for i386 using glibc 2.1 with gcc2.96, 2.2 with gcc 2.96, 2.2 with 
2.96 and 2.2 with gcc 3.0 eventually. May as well just figure on using source 
for everything. While I personally use source for 99% of my software that 
doesn't come with a distro this isn't really a problem, but it's a nighmare 
for uninitiated users. It's even more of a mess than the differences between 
different versions of windows.


On Friday 23 February 2001 18:04, you wrote:
> On 02.23 Paul Giordano wrote:
> > http://gcc.gnu.org/gcc-2.96.html
> >
> > While I understand that the cooker's generally considered "alpha" code,
> > many of us see it as the precursor to the next release - are you planning
> > on releasing Mandrake 8.0 it with gcc 2.96, clearly against the
> > developer's specific advice (as in the above URL)? I really want to try
> > this out, but I can't see doing so with the current libstdc++ locked into
> > so many rpm's at the 2.96 code base.
>
> Don't look at the nowadays gcc-2.96 in cooker like the initial alpha
> snapshot. It is closer to the 3.0 snapshots.
>
> gcc-2.96 has many changes that make it generate much better code than any
> gcc before, AFAIK. And to be more correct and efficient, especially g++.
> The problem was that when RedHat and Mdk took the source
> snapshot to ship gcc-2.96 the optimizer was very broken in certain silly
> things. But with the level of patching it has suffered since then, it is
> really near a real compiler. I have been building kernels with it since
> 2.2.18 - 2.3.x and now it compiles perfectly my 2.4.2-ac3. It does not
> imply that there was still some obscure driver used not so often which
> can still trigger some gcc bug (and many of that 'bugs' are not bugs, but
> badly written code relaying on gcc doing low level things in a certain way
> you should not suppose, like guessing which alignment the compiler is going
> to do inside a struct, how will it pad the struct, and so on).
>
> In my oppinion (I also cried 'how can they ship that') using 2.96, even in
> alpha or beta stage, has helped to clean much code.

-- 
Jason Straight

Reply via email to