This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: PATCH: Re: Do we really want to use i586 code for i686?
On Mon, Nov 12, 2001 at 03:40:42PM -0500, Roland McGrath wrote:
> > On Mon, Nov 12, 2001 at 03:31:33AM -0500, Roland McGrath wrote:
> > > > I don't think we should apply Implies outside of the subdirectory.
> > > > Here is a new patch. That is A implies B in libc doesn't mean A implies
> > > > B in linuxthreads, vice versa.
> > >
> > > Why do you want this change? I don't think it's desireable. The current
> > > behavior is by explicit intent. It makes sense add-ons sysdeps/ to act as
> > > if superimposed on the libc/sysdeps tree. Your change requires add-ons to
> > > include Implies files for every Implies file in any libc/sysdeps/ directory
> > > that they want to add on to.
> >
> > That is debatable. If that is what I want, I can do that. But I don't
> > believe Implies from add-ons should be applied to libc/sysdeps.
>
> Ah, but you refuse to actually debate! As usual, you just repeat your
> position as if that were an argument for it. It is very useful to have
> add-ons Implies files affect the main sysdeps list. Take for example
> libc/sysdeps/pthread, where aio is implemented in terms of pthreads. The
> linuxthreads add-on has an Implies file containing "pthread", so using the
> add-on enables the sysdeps/pthread code in libc. A different add-on might
> provide a different pthread implementation, but use an Implies file to
> enable that same code.
The problem with it is it may imply things libc clearly doesn't want. I
don't believe Implies from addons should affect libc at all. We can
treat `pthread' as `elf' in configure.in. We can add `pthread' when
a pthread package is provided.
H.J.