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

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

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.  Hence none
>     of the Mesa developers are likely to have tested under RedHat to any great
>     degree.
> 
>   * As you have noticed, many other programs (Quake for instance) do not bother
>     to check that the current rendering context is valid.  The only reason that
>     PLIB really needs to do it is that it's used by a hundred applications and
>     I have no control over whether one or other of them is breaking the rules.
>     Hence I need to protect the library from false allegations by doing that test.
>     Quake has no need to do that - they know that they open the OpenGL window
>     and that it opened without error and hence there *MUST* be a valid rendering
>     context.   PLIB cannot be certain that this has happened if that application's
>     author screwed up.
> 
> > 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.
> 
> 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.  The GCC
> team objected - RedHat didn't listen.  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' - 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.
> 
> So basically, they TOTALLY screwed up RH 7.0.  Everyone complained bitterly
> but *AMAZINGLY* they didn't go back to 2.95 in RH 7.1 - so the GCC team
> (who get most of their funding from RedHat) gave this "bogus" version the
> number 2.97...but it's still just as broken.  Mandrake (as usual) blindly
> followed RedHat's lead - so Mandrake 8.0 is also "broken".
> 
> 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.
> 
> 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.
> 
> They shouldn't be allowed to get away with this - so, I recommend that you
> keep RedHat's support lines as busy as possible with these complaints - either
> that or switch to Debian, SuSE, Slackware or one of the smaller distro's.
> 

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

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

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