Huh? I'm sorry, but I don't undestand this. Both *what*?
Erik's response was to the question of how long we keep binary
compatibility for old apps, and suggested a solution (personalities)
for moving to larger data types without breaking compatibility.
I would personally suggest new syscalls for this, but it is the
same problem either way.
>Nobody argues that we'll move to glibc ultimately,
For new development, yes.
>so the commercial software developers will have to support it.
If they continue to support Linux.
>Hopefully it's gonna be the last substantial libc change.
That's what what was said about libc 5. (Yes, I understand the
technical improvements in libc 6 -- but I understood the technical
improvements in libc 5, too...)
>BTW, Some of the commercial ISVs may find glibc very attractive, since
>the threads support in it is better than in libc. Let alone the
>locale.
That's quite correct. The issues is supporting old BINARIES that
have not been updated. There are still a.out-only binaries in
daily use!
>So anyway, why don't make the same thing people made for moving to
>ELF? I guess RedHat is a perfect candidate to start it... ;-) (just a
>hint, no pun intended)
Take a look at our current source tree. We've already publically
announced in several places, including this mailing list, that bar
disaster we'll be using glibc for our next major release on Intel
as well as Alpha.
That's not the issue we are discussing, though. The issue is all
the old binaries that are in use.
michaelkjohnson
"Magazines all too frequently lead to books and should be regarded by the
prudent as the heavy petting of literature." -- Fran Lebowitz