Ulrich Drepper wrote:
>
> Gareth Hughes <gareth@precisioninsight.com> writes:
>
> > Yes it does work, it's just not binary compatible.
>
> But this is not acceptable. Well, I'm used to not being listened to
> by kernel developers. So let's wait until other people get hit. Just
> make sure your name comes up immediately so that people know who to
> thank for this.
All I want to see happen is user-space SSE support. I'm not trying to make your
life difficult.
To properly support user-space SSE, we will have to make things binary
incompatible. Do you have a better suggestion of how to handle the new FPU save
format in signal contexts? If so, please let me know. This is the best method
I've been able to come up with.
> Fact is, people will complain and therefore those who have to care
> about compatibility will create patches which in turned will lead to
> incompatible systems, even among 2.4 systems.
>
> (Even compiling & testing glibc with the new headers but a slightly
> older kernel fails.)
You shouldn't compile the new headers with an old kernel. I thought I made that
pretty clear. Pre-2.4 kernel headers => old sigcontext headers. 2.4 kernel =>
new sigcontext headers. If you're compiling glibc on a pre-2.4 kernel, you must
use the old format. There is no sane way to make it work otherwise.
The 2.4 kernel is a nice break point. If you are using an application that
plays with the FPU state, then you either use the pre-2.4 kernel, corresponding
glibc and old sigcontext headers. If you are using the 2.4 kernel, you must use
the latest glibc (with the headers I sent you used for compilation) and new
sigcontext headers.
-- Gareth
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Jun 07 2000 - 21:00:24 EST