Re: Grave concerns on releasing alpha with the rest of potato
"Christopher C. Chimelis" <chris@debian.org> writes:
> On 18 Feb 2000, David Huggins-Daines wrote:
>
> > 1) Constant spew of unaligned access messages from all programs
> > written in C++. This is not acceptable for a release. People are
> > working hard (Jason did a great job of isolating the problem) on
> > this but it may not be possible to fix it before release, and we
> > cannot hold up other architectures for it.
>
> Agreed. In fact, I doubt we can/will fix it before that time,
> unfortunately. I lack the time to really beat on a solution enough right
> now.
I'm investigating it now ... unfortunately my dysfunctional internet
connection at home and a lack of disk space at work have been
conspiring to stop me from working on it all week. Hopefully the
wires will cooperate today and I can poke around in gcc and glibc
source for the answer.
> > 3) Our C library can't even be built with the compiler we are
> > shipping. Enough said.
>
> This is not true at all anymore. The appropriate patch has been included
> in Debian's gcc packages to allow glibc (and many other math packages) to
> be compiled now. I'm going to get the new glibc packages compiled today,
Wow! Excellent.
> fyi. Also, the reason that we don't autobuild glibc, gcc, and a few other
> packages is because of their importance. If they should somehow be
Yeah - by the way, please upload a new glibc *soon*, the current one
is really, really, really broken - there is no ldd and no way to get
one, and gtk+ refuses to install. This is basically what prompted me
to rant, as I installed potato and basically could not use it for
development *at all*.
> > providing exception-handling symbols while theirs doesn't, C++
> > programs compiled on Debian can't run on Red Hat anyway since we
> > are using libstdc++2.10.
>
> Great point! I never thought of this and would break compatibility anyway
> (has anyone on -devel noticed that fact yet?). I hear that RH6.2 is in
I can probably build libstdc++2.9 packages for alpha in a chroot at
work - the machine there dual boots Debian and Red Hat too so I can do
compatibility testing. (Again, the tone of my rant was motivated by
my distaste at having to boot back into Red Hat to get any work done
at all :)
> have forseen these events. Also, I wish I could say that I kept a RH
> system around to check these things (if I did, I would've seen this
> already), but I can't.
I basically have to dual-boot (or possibly triple-boot with SuSE) at
work, so I should be able to do this from now on.
> with. No, it's not because the version numbers should go up. It's more
> because gcc 2.95 is technically a superiour compiler to egcs 1.1.2 and,
> believe it or not, provides better support for Alpha than before. It was
I agree without question that it's a superior compiler (especially for
C++). I'm not so sure about its Alpha support. There are
*definitely* some regressions from 1.1.2 to 2.95.x, the most glaring
one being the unaligned relocations in libstdc++ (although it's also
possible that this is a binutils problem). Also another thing that
prompted me to rant was my inability to compile a 2.3.47 kernel with
2.95.2 (internal compiler error).
The other thing that bothers me about 2.95.x is that it really does
not look like a released version to me. I'm not one to second-guess
Cygnus's motivations for their release cycles, but I get the feeling
that 2.95 was released simply in order to have a release named "gcc".
Things like the fact that we are still facing another round of C++ ABI
breakage in gcc 3.0 and the flip-flop on -fstrict-aliasing don't sit
well with me. But then again I'm not a toolchain hacker, so this is
probably just more paranoid ranting on my part :)
I also find it ironic that Red Hat 6.2beta still uses egcs 1.1.2.
Essentially, Red Hat has given the released version of their own
toolchain a vote of no-confidence.
> unforseeable that RH would base their distribution on egcs 1.1.2, but the
> big argument is, do we, as a distribution, use RH as a standard that we
> must follow or do we have our own development cycle?
True.
> of gcc to begin with (among other things). Right now, there are no easy
> answers anyway and, if needed, I say we just opt to skip the release cycle
> for Alpha or at least postpone it. I know it's never been done before,
> but why couldn't it be?
It could be done. I guess we can just keep plugging away at the bugs.
Since this is free software, we have the source and we can,
theoretically, fix them.
Cheers
Reply to: