Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking
Daniel Jacobowitz wrote:
On Wed, Nov 03, 2004 at 12:02:29AM +0100, Eric Valette wrote:
2) When linking in dynamic mode, nptl implementation is dynamically
chosen while the includes that have been used to compile the program
arethe linuxThread ones,
This is only true if your kernel supports NPTL.
Any 2.6 kernel supports them and 2.6 being the _current_ stable branch
isn't it... I guess sarge will come with an optionnal 2.6.x x>=8. Would
you bet that more than 80% of the users will chose a 2.6 kernel if they
know they can use it... Or will sarge be already obsolete when it will
endly comes out? (glic in other distribs is already 2.3.3 + cvs 2.3.4)
nptl-dev provides headers and static libraries for NPTL, which we don't
provide at all.
This is a problem because benchmarks and POSIX compatibility tests have
already proven that NPTL ptread implementation is far superior to
Linuxthread one, besides being still actively developped...
In fact most distributions do exactly the same as
Debian with their default headers and dynamic libraries.
So because other distrib mades bad choices, Debian must follow. Good
point. I will check and report if this is even true latter on. Anyway,
you will not argue that using linuxThread's pthread.h and semaphore.h
for compiling nptl pthread programs is a good choice? Are you? I made a
simple test that consist in taking the debian patched glibc-2.3.2,
compile it with enable-add-ons=nptl and --prefix=/usr/local/nptlstatic
And the checked what includes are installed, its the NPTL ones not the
linuxthread ones. So the bug comes from debian not from original glibc...
If you have compatibility problem, then provide libc6-linuxthread and
libc6-nptl and their respective -dev. libc6-nptl pre-install can easilly
check that uname -r reports > 2.6.0 and refuse to install.
2) As default linking is dynamic, default includes should be the
NPTL ones and not the linuxThreads ones,
This does not work correctly because the static linker (i.e. GNU ld)
does not search the hwcap directories. It thinks the default libraries
being linked to are the LinuxThreads ones. That's why we provide
LinuxThreads headers.
Someone made nasty things to enable the dynamic linker to dynamically
choose between NPTL vs linuxThread implementation and now you use it for
justifying the actual mess? Another good point!
The point is that on a 2.6 kernel, with dynamic linking, NPTL library is
used, and linuxThread include are used by gcc to compile the program and
that glibc code is not expecting this.
3) If someone find a reason to not use NPTL in static mode, then
a diffrent package for static linuxThread code should be availiable
Like, the bulk of deployed Linux systems which can't run NPTL
applications?
I do not care so much about deployed systems :
- If they did not compile the software themselves then they have no
problem,
- if they did compile it, after upgrade, it is likely to not even load
due to incorrect dynamic library version. And they will need to
recompile anyway. If they recompile the problem will go away,
We can revisit these choices after sarge.
I disagree. You will ship the first NPTL enabled distrib with completely
wrong header files? If you compile and install unmodified glibc, it
install different headers than Debian does isn't it. Is the original
glibc wrong?
I would also like to recall that static linking when optimal/soft RT
performance are required is something still very usefull as mlockall and
dynamic libraries do waste so much physical memory (e.g 70 Mb VmSize vs 10 Mb).
If you only have one application that matters, and thousands of shared
libraries, maybe. Using mlockall to keep a shared libc.so in memory
takes 1.3MB.
(e.g 70 Mb VmSize vs 10 Mb) is a real figure. I can provide the details
off list...
--
__
/ ` Eric Valette
/-- __ o _. 6 rue Paul Le Flem
(___, / (_(_(__ 35740 Pace
Tel: +33 (0)2 99 85 26 76 Fax: +33 (0)2 99 85 26 76
E-mail: eric.valette@free.fr
Reply to: