[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Grave concerns on releasing alpha with the rest of potato


I've just done a fresh install of potato on the DS10 here at work, and
I have some rather grave concerns about our readiness for release on
this platform.

First, the good news (yeah, that's the wrong order to do this in, but
oh well...): boot-floppies (as they stand in CVS - I'm putting off
building a release for reasons I'll get into later) are *definitely*
on track.  I dare say that they are already much better than the ones
we released with slink, though that's not too hard.  Documentation is
also coming along well I believe.

Now, the bad news:

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.

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.

3) Our C library can't even be built with the compiler we are
   shipping.  Enough said.  This makes it particularly hard for us to
   deal with the latest rearrangements of the glibc dependencies since
   glibc can't be autobuilt.  At the moment I'm in a tough situation
   here because I need to use my workstation for development, but many
   very important packages (gtk+ in particular) are uninstallable
   until I have new glibc packages that contain /usr/bin/ldd and
   provide gconv-modules.

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.

In short, our system is in a mess due to circumstances entirely beyond
our control.

In every case, the culprit is obvious:

****** GCC 2.95 IS THE ROOT OF ALL EVIL (on alpha at least) *******

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

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.

Reply to: