NTPL support integration with Debian's glibc packages
[Please CC me on replies.]
Hello glibc maintainers,
Jeff Bailey and I have spoken on IRC a couple of times over the past few
days about the intersection between NPTL and Debian's glibc packages,
and he encouraged me to mail this list after he brought me up to speed
on the current efforts.
Progeny is interested in seeing NPTL support, at least at the C library
level, in Debian sarge. Since the Release Manager's deadline for major
changes to major packages is drawing nigh, we'd like to find out what we
can do to help make this happen.
I got the impression from Jeff that most of the work has already been
done by GOTO Masanori, but integration and further work has been a
little delayed because of the importance of getting glibc's
release-critical bugs squashed.
I'm familiar with Christian Leber's packages, but unfortunately those
are mainly useful as a proof-of-concept; Jeff explained that Debian's
glibc needs to retain LinuxThreads compatibility by default at least for
one more Debian distribution release.
Here are the major points as I understand them:
* A libc6-nptl package will be created which provides a libc6 shared
object. This package will not ship a shlibs file; instead, packages
requiring NPTL support will be expected to depend on it explicitly.
(The lack of support in the packaging system for versioned Provides:
makes use of a shlibs file imprudent.)
* The dynamic loader (ld-2.3.1.so) will have to be hacked with a patch
from Red Hat that performs runtime checking of whether an object needs
to use the NPTL version of libc6 or not.
* A libc6-nptl-dev package will be created. Details on this appear to
be a bit fuzzy still. Jeff seemed to think that the entry points in
the libc6.so and libc6-nptl.so objects will be the same. I.e., the
symbol offsets won't change despite the differences in the threading
implementation. Do we know this to be true?
* The package build process will obviously have to be changed to support
building the C library twice; once with the stock threading
implementation, and once with the NPTL patch applied.
* Open question: will libc6-nptl (and libc6-nptl-dev) have those names
even or architectures that use the package name "libc6.1" instead of
"libc6"?
* Open question: how will the new -nptl packages interact with the
existing alternative versions of the C library package? E.g., the
64-bit version, the SPARCv9 version, and so forth. It seems to me
that it could get complex to have eight different versions of the C
library on SPARC:
32-bit, LinuxThreads, SPARCv(something-less-than-9)
32-bit, LinuxThreads, SPARCv9
32-bit, NPTL, SPARCv(something-less-than-9)
32-bit, NPTL, SPARCv9
64-bit, LinuxThreads, SPARCv(something-less-than-9)
64-bit, LinuxThreads, SPARCv9
64-bit, NPTL, SPARCv(something-less-than-9)
64-bit, NPTL, SPARCv9
...and then we'd need a -dev package for each of those as well?
For non-UltraSPARC 64-bit architectures, we'd still need four
different shared library packages and four different -dev packages for
full coverage, right?
I'm available to work on these issues (once a consensus is reached, if
it hasn't been already, on the open questions). Please let me know
which plow I need to hitch myself to. :)
--
Branden Robinson | GPG signed/encrypted mail welcome
branden@progeny.com | 1024D/9C0BCBFB
Progeny Linux Systems | D5F6 D4C9 E25B 3D37 068C
| 72E8 0F42 191A 9C0B CBFB
Reply to: