Re: Grave concerns on releasing alpha with the rest of potato
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.
> 2) Many, many programs do not build correctly due to internal compiler
> errors, or do not work correctly due to miscompilation or
> misoptimization. I'm working on producing testcases for these bugs
> so that they can be forwarded to the gcc lists, but even then I'm
> doubtful that they will be fixed in the gcc 2.95.x release stream.
Also agreed. All compiler iterations for Alpha have had problems, mostly
because Alpha really isn't an arch that is owned by a few million people
on the average. Also, because of some pretty widespread changes in the
future of gcc, I doubt many more things will be done to 2.95.x.
> 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,
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
miscompiled or should have an unanticipated problem, the generated debs
could trash all of our systems. I've held up on compiling some glibc
versions because of problems and, believe me, we ALL were lucky in those
cases that they weren't autobuilt. In other words, those packages deserve
(rather than require) a bit more personal attention than the rest.
> 4) We are not binary-compatible with Red Hat 6.1 and 6.2beta.
> (However as mentioned in an earlier message this is probably not
> our problem). Aside from the big horrible problem of our libc
> 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
the beta stages now, so I guess we'll have to check that out and see what
they're doing in both regards.
> In short, our system is in a mess due to circumstances entirely beyond
> our control.
True.
> In every case, the culprit is obvious:
> ****** GCC 2.95 IS THE ROOT OF ALL EVIL (on alpha at least) *******
Argh! No.....
> I would like to propose that the Alpha distribution revert to egcs
> 1.1.2 for potato, recompile glibc and all c++ programs to match, and
> leave gcc 2.95.x in woody, so that we can work on fixing the bugs
> there.
That's ALOT of work and should really be discussed on -devel. Keep in
mind that when we started potato, RH5.2 was still out and we could never
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.
On top of all of that, there are some real
misconceptions floating around as to why we're using gcc 2.95 to begin
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
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?
> It's okay that we put unstable software (such as CVS versions of
> glibc) in the unstable release with the expectation that they will be
> fixed by the time the next release rolls around. HOWEVER, if these
> unstable versions are NOT fixed, we MUST back them out! It is
> irresponsible to our users to do otherwise. We CANNOT continue to
> assume that version numbers can only go up.
Believe me, nobody here just expects version numbers to increase. I'm
waiting on the glibc maintainer to comment on our current situation before
bringing the whole thing up on -devel. I also wouldn't consider gcc
2.95.x to be "unstable". EGCS 1.1.x had NUMEROUS bugs that we either
worked around or caused us to not compile certain packages, but I would
consider EGCS more "unstable" simply because it was a prerelease version
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?
C
Reply to: