This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Re: Do we really want to use i586 code for i686?


> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]