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?
- To: "H . J . Lu" <hjl at lucon dot org>
- Subject: Re: PATCH: Re: Do we really want to use i586 code for i686?
- From: Roland McGrath <roland at frob dot com>
- Date: Mon, 12 Nov 2001 16:58:40 -0500 (EST)
- Cc: GNU C Library <libc-alpha at sourceware dot cygnus dot com>
> You seem to ignore my bug report:
>
> http://sources.redhat.com/ml/libc-alpha/2001-11/msg00052.html
No, I just don't agree with your conclusions. That is a bug in
linuxthreads that should be fixed. One way to fix it would be to move the
contents of linuxthreads/sysdeps/i386/i586/ to a differently-named subdir
that is referenced in linuxthreads/sysdeps/i386/i586/Implies and
linuxthreads/sysdeps/i386/i586/i686/Implies.
Another way would be to add a different flavor of Implies file (or a marker
within the file, or whatever) for the Implies-within-add-on semantics.
linuxthreads has two Implies files. For
linuxthreads/sysdeps/unix/sysv/linux/Implies, the current behavior is
right, and your changes would break (e.g.) the aio code. For
linuxthreads/sysdeps/i386/i586/, the current behavior does not match the
author's apparent intent.
> My point is no addon should change libc. Pthread seems to be a special
> case. But it should be treated as such.
The sole purpose of add-ons is to change libc.
Something that is truly separate belongs in its own package.