"Christopher C. Chimelis" <[EMAIL PROTECTED]> 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
