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

Re: glibc 2.1.95 (5th test release)



[ no longer relevant to libc-alpha... ]

On Sat, Oct 14, 2000 at 04:26:39PM -0700, Geoff Keating wrote:
> > Date: Sat, 14 Oct 2000 18:45:48 -0400
> > From: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
> > Content-Disposition: inline
> > User-Agent: Mutt/1.1.9i
> > 
> > On Sat, Oct 14, 2000 at 03:42:20PM -0700, Geoff Keating wrote:
> > > No, because previous applications used the old __gmon_start__
> > > mechanism which didn't involve weak symbols.
> > 
> > That's what I thought.  Thanks.
> > 
> > > > All of a sudden I'm glad we haven't built debian/ppc packages of the
> > > > new libc yet...
> > > 
> > > There are a few more changes to come, too, related to .protected and
> > > .hidden.  I hope that very soon ppc glibc will build cleanly; x86 is
> > > now clean too, and so we may actually get a release!
> > 
> > How severe are these?  Worth sticking with 2.1.3 a bit longer for?
> 
> I think that unless you have to make a release next week, you probably
> want to wait for the patch.  It might not help just to use glibc
> 2.1.3, unless you also use gcc 2.95.*.  (By comparison, if you use the
> new glibc, you should also use new gcc and new binutils.)
> 
> I'm now building glibc with a Red Hat custom toolchain which branched
> 2000-09-12 (it would be related to gcc a few days earlier).  There're
> two bugs in later gcc involving reload inheritance and register
> preferences which together cause pow() to be miscompiled.
> 
> It strikes me that it might be a good idea to set up a branch on
> sourceware gcc to mark the date of the C++ ABI that glibc 2.2-based
> ppc linux distributions use, if y'all want to share the same ABI.  My
> suggested date would be the snapshot before 20000905T000500Z.

I'm not at all sure I want to go this route.  We're more or less
committed to using the same GCC on all our architectures.  After the
amount of flak Red Hat is taking for using a snapshot, even with a good
understanding of the issues, I'm not sure that it's a good idea to do
the same.

If I understand correctly, Debian had been looking vaguely at testing
GCC snapshots, but was certainly not planning on shipping with them
until at least much closer to 3.0.

What are the odds we could use this to merge the relevant fixes onto a
2.95 branch again?  I understand that the differences are staggering
and the manpower short, but is it a feasible task?  I don't have a
whole lot of time, but I would be willing to do what I can to see this
happen.

Dan

/--------------------------------\  /--------------------------------\
|       Daniel Jacobowitz        |__|        SCS Class of 2002       |
|   Debian GNU/Linux Developer    __    Carnegie Mellon University   |
|         dan@debian.org         |  |       dmj+@andrew.cmu.edu      |
\--------------------------------/  \--------------------------------/



Reply to: