[Fwd: ..gcc-3.x.y & RH7.z, was: [Plib-users] Fwd: Re: flightgear problem]

[Arnt K. <ar...@c2...>]

"Trond Eivind Glomsrød" wrote:
> 
> Arnt Karlsen <ar...@c2...> writes:
> 
> > On Sun, 26 Aug 2001 00:10:59 -0500,
> > Steve Baker <sjb...@ai...>
> > wrote in <3B8...@ai...>:
> >
> > > pieter bonne wrote:
> > > >
> > > > greetings,
> > > >
> > > > First of all, thanks for such a lengthy response.. It's all quite clear to me
> > > > now.. So in a nutshell, the problem I am experiencing is due to a bug in that
> > > > version of mesa.. I can't really comprehend how such an important call can
> > > > get bugged, but anyway.. Due to that bug, the context doesn't "seem" ready to
> > > > flightgear (using plib)..
> > >
> > > Well, there are two reason why that may have sneaked through
> > >
> > >   * It only seems to affect RedHat 7.x and Mandrake 8 and most 'power users'
> > >     have abandoned those two distro's following the gcc debacle.
> 
> "Informed" users such as yourself? Happily, there is no such trend.
> 
> > >     Hence none of the Mesa developers are likely to have tested
> > >     under RedHat to any great degree.
> 
> I'd like to see you substantiate that claim... but then, I'm probably
> expecting too much. Here you have a great, flaming article - facts are
> bothersome.
> 
> > > > I don't think the fact of the 2.96 compiler has anything to do with all
> > > > this.. All packages I installed are compiled by this compiler!
> > >
> > > Yes - but the problem only shows up on RedHat/Mandrake and the only thing that's
> > > really obviously in common that could possibly have an effect is the C compiler.
> 
> If this is a Mesa issue, I'd rather suspect that it's caused by our
> Mesa library - it's changed a bit, in order to provide GLX for cards
> still using XFree 3.3.x servers.
> 
> Of course, this doesn't rule out a problem in the code or compiler (of
> these, a problem in the code is far more likely).
> 
> > > You *are* aware of the 2.96/2.97 compiler "issues" - right?   The deal is (in
> > > a nutshell) that the last released version of the GCC product was 2.95 - they
> > > were working towards the major new 3.0.0 release but didn't get there in time
> > > to make the RedHat 7.0 release date.  What RedHat did was to grab the "weekly
> > > snapshot" of the pre-3.0 CVS load and release that into the world.
> 
> Not true. We grabbed a snapshot, and then QAed it, fixed it and
> worked hard on it.
> 
> The reason? 2.95.x was unacceptably buggy - it couldn't even compile
> glibc (you'll note that this is still the case for gcc 3). The
> performance on non-IA32 systems was also very bad. Compliance to C++
> standards was also severely lacking. And there was no support for IA64
> at all. When a release was obviously sorely needed they chose do
> everything at once, resulting in a very late and not very good gcc
> 
> The result? We've had the best compiler around for a year, and when we
> switch we'll get a somewhat mature gcc 3 (the "final" ABI wasn't as
> final as it should have been on all platforms either). 2.96RH is
> arguably still better than gcc 3 in many areas (less bugs), while
> being better than 2.95.x and not as good as gcc 3.0 in other areas
> (like C++ compliance).
> 
> > > The GCC team objected - RedHat didn't listen.
> 
> They did not complain before shipping (and remember, we had a public
> beta). Our internal compiler group were aware of the plans, and had
> recommended it. This includes members of the gcc steering committee
> (not surprising, as Red Hat includes  former Cygnus and thus is a huge
> contributor to gcc). There was a commonications misunderstanding to
> the rest of the gcc committee, and we should have marked it more
> clearly as a "Red Hat" release. Politicswise it could have been
> handled better, technically it was the best choice  .
> 
> I've even talked to Mark Mitchell myself, and his issue was that we
> didn't brand it properly - the initial release didn't refer to
> bugzilla if anything went wrong, to give one example.
> 
> > > The Kernel team said that the kernel wouldn't compile with 2.96 so
> > > RedHat also released the 2.95 compiler under the name 'kgcc'
> 
> There was a bug in the 2.2.16 kernel  shipped with RHL 7, and the
> kernel is very compilerdependent (including handcoded knowledge of how
> the compiler interacts with assembly, how structs are laid out) etc -
> thus, using egcs 1.1.2 (we've never shipped 2.95.x) was the safest
> choice. An absense of problems doesn't mean there aren't any others
> will run into.
> 
> > > - which you'll have on your disk.  However since 2.95 and 2.96
> > > can't share the same libraries (and 2.96 can't share with 3.0 either), you can't
> > > just recompile things like PLIB and Mesa using kgcc.
> 
> Mesa is a C library, you can mix and match whatever compilers you
> want.
> 
> > > So basically, they TOTALLY screwed up RH 7.0.
> 
> No, we did not. It's a good release, with a good compiler. Better than
> any other alternatives at the time
> 
> > > Everyone complained bitterly but *AMAZINGLY* they didn't go back
> > > to 2.95 in RH 7.1
> 
> Of course not. We need to preserve binary compatiblity for C++. 2.95.x
> wouldn't have been compatible with anything we've ever shipped. No gcc
> compilers haver ever been binary compatible with other version
> wrt. C++ (not counting patchlevels - 2.7.2 and 2.7.3 are compatible,
> 2.7.x and 2.8.x are not)
> 
> > > - so the GCC team (who get most of their funding from RedHat) gave
> > > this "bogus" version the number 2.97..
> 
> No, they didn't. They've never released it. 2.96RH is the result of
> gcc being open source - if something is broken, you can fix it
> yourself.  They increased the version number from 2.96 to 2.97 in CVS
> to avoid confusion.
> 
> > > It is unsuprising under the circumstances that none of the serious developers
> > > out there are particularly inclined to try to diagnose problems that only
> > > affect RedHat 7.x or Mandrake 8.x under these circumstances.
> 
> I've not seen any take it that way, considering the fact that 2.96RH
> is the most stable compiler out there now.
> 
> > > Personally, I think RedHat is becoming like another Microsoft - deliberately
> > > using incompatible versions to lock people into their software distro - hoping
> > > that their market share is large enough to lock people in.
> 
> The software is GPL. Anyone can ship it (as you've seen, Mandrake has
> done that). Standards for binary compatibility explicitly say "don't
> use C++ dynamic libraries". We've no intention of locking people
> in. Offering the best technology around is a much better way (even if
> it takes extra work, like gcc), and this is what you'll find in Red
> Hat Linux.
> 
> > ..how about Red Hat 7.z/Rawhide and gcc 3.x.y?   TEG?
> > Will gcc version 3 onwards fix the Red Hat 7.z "gcc-2.96/7" problem?
> 
> This isn't a software proplem, it's as people problem. Lack of
> knowledge can be an inflammatory thing.
> 
> 2.96RH will of course remain the standard compiler through the 7.x
> series. For the next major series, we intend to move to gcc 3 if it's
> mature enough at the time (if not, it'll just be another 7.x,
> probably).
> 
> --
> Systems Engineer - OS Engineering; Red Hat, Inc.
> ************************************************
> Want to help translate for your language?
> http://sources.redhat.com/rhl/i18n/

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.