This is the mail archive of the
libc-hacker@cygnus.com
mailing list for the glibc project.
Re: A patch for glibc 2.0/2.1
- To: hjl@lucon.org
- Subject: Re: A patch for glibc 2.0/2.1
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Sat, 23 Jan 1999 17:28:44 +1100
- CC: kettenis@phys.uva.nl, libc-hacker@cygnus.com
- References: <m103wIL-00038dC@ocean.lucon.org>
> From: hjl@lucon.org (H.J. Lu)
> Date: Fri, 22 Jan 1999 22:11:45 -0800 (PST)
> Cc: kettenis@phys.uva.nl, libc-hacker@cygnus.com
> > > From: hjl@lucon.org (H.J. Lu)
> > > Date: Fri, 22 Jan 1999 13:08:13 -0800 (PST)
> > > Cc: libc-hacker@cygnus.com
> >
> > > We don't want to be flooded with ANY glibc bug reports
> > > associated with gcc. That is why I suggest we require egcs for
> > > compiling glibc 2.1.
> >
> > Then shouldn't we require a specific version of egcs?
>
> Sure we do. We do check the version of egcs.
But we allow future versions which we don't know for sure will work,
or which might require more special hacks like the C++ exceptions
things.
I meant, perhaps we should say
"glibc 2.1 should only be compiled with egcs 1.1.1".
> > I don't see why being "flooded with glibc bug reports associated with
> > gcc" is a problem. Simply forward them to the gcc maintainers, if
> > they are a gcc problem, or fix them if not.
>
> It is still a glibc problem, although it is caused by gcc. Forward
> to the gcc maintainers doesn't solve the glibc problem.
Then shouldn't we fix the glibc problem?
If this is the C++ exceptions problem, one easy way to fix it is to
take the libgcc.a routines from egcs and include them all in libc.
Sure, this means that the egcs people can't change libgcc.a (except by
adding routines, which would still work), but in practise they can't
change it now anyway, and at least it'd solve the problem permanently.
--
Geoffrey Keating <geoffk@ozemail.com.au>