Re: gcc question

["Christopher C. Chimelis" <chris@debian.org>]

On 15 May 2001, Andrew 'ashridah' Pilley wrote:

> heh. okay. the topic's ambiguous. i apoligize
> if you have any comments on this, please read
> on, it's basically a question concerning debian's
> position between 2.95/2.96 and 3.0. if you're sick
> of hearing about it. stop reading now, flame me,
> and that's the end of it :)

No flames here :-)

> anyway. i've had this discussion a few times with 
> various people, but i figure i may as well get the 
> "official" position of the debian-gcc team, regarding
> redhat's so called gcc 2.96. i'm not a compiler 
> expert, but i can understand the issues involved

I can't speak for the rest of the team, but I definitely have some
feelings regarding RH's "2.96" release...

> basically, where i personally stand, is that 2.96 is
> a redhat construct, that has bad c++ handling 
> (although i can't say 2.95 is better :) ) compared to 
> gcc 3.0. it makes things harder for developers, 
> because they have to maintain their code on two
> compilers, not one, which makes it harder for them
> (or us, since we're not using the "simple" distro.)
> and that generally, redhat were blurring the line
> by releasing something that they claimed was 
> an official stable release, which it technically
> wasn't.

This is a pretty broad statement.  RedHat acknowledged that it wasn't an
official release and never really passed it off as one, even in the
beginning.  While I don't agree with their decision, personally, I do
understand where it came from.  They were basically faced with finding a
common compiler on several platforms that worked well.  The 2.95.x
releases have serious issues with C++ on Alpha, and other platforms have
had other issues, often involving simple C code that would cause ICEs.
The snapshots at the time were MUCH better than the state of 2.95.x back
then, so they worked at stabilising a snapshot rather than trying to
backport fixes to 2.95.x.

As for maintaining code for two compilers, it's a "mixed bag".  Commercial
vendors who want to release a binary that works on all distributions
definitely run into a problem when deciding what distributions their
product will support.  If they stick with RH, then they have to decide
further whether to support 7.x or use the older compilers in 6.x and
support that.  Add other distributions, like Debian, and it gets quite a
bit uglier from their standpoint.  Unfortunately, RedHat has never played
well with others in that regard, most likely because they're a
business.  As much as some of us would like to believe that they are in
the business of being somewhat altruistic to the Linux community, I think
none of us are so oblivious to the world that we really believe it :-P

Basically, like all businesses, they will do what it takes to make their
product stand out in the marketplace, even if that means possibly breaking
binary compatibility here and there (we've gone through this kind of
situation before).

> it also seems to detract from the bug
> fixing and testing of gcc 3.0. if they'd forgotten
> about 2.96, and worked on 3.0 it'd get there 
> that much sooner, and be a better release for
> all of us...

Now this I disagree with.  I hate to say it, but the "2.96 release" got
gcc snapshots into MANY more people's hands than ever before.  I really
think that it helped to debug the upcoming 3.0 release faster (that is,
until 3.0 progressed much farther than 2.96).  I would've rather seen them
pour their efforts into fixing 2.95.x rather than going with a newer
snapshot, but they didn't.

> so, to my question: what's debian-gcc's official
> position on this matter. i know Ben is working 
> REALLY hard on the gcc 3.0 snapshots (which 
> i've tested, personally think he's doing something
> good for both the gcc team AND debian by helping
> it get tested, while not forcing people to use it)
> but where do we stand, and how do we reconcile 
> our supposed "unwillingness" to accept the redhat
> so called standard?

I've got strong feelings on the whole "RH standard" thing, and I think
everyone (at least on this list) knows them.  I don't feel like it's our
responsibility to keep up with them or to follow in their footsteps in
this regard.  We always are ahead of their game on the glibc front, so I
don't see why we shouldn't be on the gcc front as well.  On the other
hand, we do want a stable distribution, so sometimes, including the latest
and greatest isn't the best idea.  This last sentiment is why 3.0
snapshots aren't being used as the standard compiler for most platforms
for Debian -- the C++ ABI hasn't been finalised yet (or really, it hadn't
been until this past weekend) and we didn't really want to break
everything periodically should it have changed again.

I don't really consider us "unwilling" to do anything that RedHat does,
per se.  I just believe that we should determine our own course of action
rather than be forced to do what they do.  I don't personally see Debian
as a RedHat competitor simply because we don't really care about
commercial success.  What should matter to us, rather than competition, is
just putting out the best product that we can.  If we start worrying much
about RedHat's business, then we might as well adopt RPM and become
another "cookie cutter RedHat clone" distribution.

> are there any technical issues
> that would be usable against 2.96 that are pertinent
> to the situation? or is it just not worth the trouble 
> doing the "stepping stone" approach that redhat are
> using by forcing themselves to do the gcc dance again
> when 3.0 comes out?

You said it best -- RedHat will have to do the dance again, and I think
that they won't like it much :-P  In reality, though, they do have some
nice autobuilders over there, so it shouldn't be too tough for them to
rebuild their C++ packages when gcc3 is finally out (circa mid-June,
btw).  The C++ ABI has definitely changed, so their 2.96 version isn't
binary-compatible with prior versions, but again, that can all be amended
by recompiling.

> thanks for a) reading b) replying if you DO have comments
> c) making debian work :)

No prob...I'm always good for a rant here and there :-P

C