Re: gcc question
On Tue, 15 May 2001 11:00:47 -0400 (EDT), Christopher C. Chimelis said:
>
> 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 :-)
and i'll definently deferr to you on technical points.
>
> 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.
true. i believe we're using gcc 3.0 snapshots for that on things like hppa and
ia64
of course, those aren't really released (debian distro wise) yet, so it's not
that
big an issue, i guess.
>
> 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
there's another side to that that i'd forgotten about. if company xyz
releases their product zyx that's dynamically compiled (hello stardivision :) )
then obviously, we'll run into problems. however, i can easily say that
compiling
them statically, while it's a possible waste of space, WILL get around the
binary compatability problems (at least, it should.)
> 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
which reminds me. when gcc 3.0 gets released, (which is supposed to be
the 15th of june, surprisingly.) how will debian go about switching to it?
(for x86 at least.) just changing the default compiler, and letting packages
get upgraded as they go? or are there are few packages that, when
recompiled (the dynamic linker?) that will mean that everyone who doesn't
want their packages to break have to compile them again? or is there a
plan to get around that?
>
> 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).
true. ms do it all the time, and seem to get away with it, by and large.
>
>
> 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 i've recently found out. many of the bug fixes have been applicable to
both trees. i retract the statement.
>
>
> 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.
heh. everyone at the Linux/unix consultancy i work at was remarkably
surprised. especially one person whom i'd had an argument about gcc with
lets say he was unimpressed when he found out that practically the next day
the release date had gone from "when i'm a grandfather" to "next time i shave"
:) wether it actually sticks to that date will be interesting to find out.
>
> 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.
speaking of which. rpm is supposedly in the lfs. i personally don't see what it
has to do with standards at all. a standard tool wrapper, yes. a standard tool
no. but that's my take on that issue.
>
>
> 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.
and soon. (heh. redhat 8.0 will be sporting gcc 3.0 as it's claim to fame. uh.
yay)
thanks for the comments.
Reply to: