Re: Grave concerns on releasing alpha with the rest of potato
On 19 Feb 2000, David Huggins-Daines wrote:
> 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.
Great! Good luck and I hope you can get a good solution. I'd be happy to
recompile/upload anything needed....
> 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*.
It's being uploaded today and, with all luck, should be installed today as
well. To ensure things go well, I'm uploading a new deb for 'make' since
apparently there was a bug in make exposed by the glibc changeover.
> 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 :)
It should be easy to build. I did this awhile ago when libstdc++ versions
changed on i386 (I did it more for my own stuff that I just didn't feel
like recompiling).
> 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.
Great, thanks!
> 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).
Doesn't surprise me. Believe it or not, I've ran into less ICE problems
with gcc 2.95.x than with prior egcs versions. The newer gcc snapshots
appear even better (I try to compile snapshots weekly).
> 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 didn't like the -fstrict-aliasing situation either. Granted, I still
agree with the steering committee's initial responce of "fix the code
since it's not compliant anyway", but it would leave alot of people in the
dark that rely on the old behaviour. It also weakened alot of people's
trust in the direction of gcc.
> 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.
I believe this is because the upstream gcc 2.95.2 still doesn't contain
the patch that we've included (for complex support on Alpha), so they are
still unable to compile a glibc package with the vanilla gcc 2.95.2.
> 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.
Yep, that's the way I see it. A release's quality is important, but isn't
carved in stone, so to speak. We could always update it if needed.
C
Reply to: