Hi,
While I do understand that debian 3.1 is the most important things most
of you are working on, I would like to bring your attention to the
actual status of libc6-dev and specifically on the incoherences that
exists between the pthread related includes, the dynamic libpthread.so
library and also the fact that a different pthread implementation is
chosen in static (linuxThread) and dynamic (NPTL) mode.
I have been recently used debian on an embedded RT system where static
linking is required due to mlockall (mlockall + dynamic library = 70 Mb
required, mlockall + static library = 10 Mb required, physical memory
size = 64 Mb so dynamic library is not an option). That's why I have
cc'ed the debian-embedded list.
I can of course rebuild the library myself but I think that actual
status is just a mess. I have for example no clue (except of course the
weight of history and the fact that NPTL is not availiable on all
processors) of why NPTL is not used also in static mode.
Proposal to enhance things are attached in the bug report. Comments are
welcome.
Have a nice day,
--
__
/ ` 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: [EMAIL PROTECTED]
--- Begin Message ---
Package: libc6-dev
Version: 2.3.2.ds1-18
Severity: grave
Due implementaion decisions made to have NPTL threads availiable when
possible, the actual status of libc6-dev is almost incoherent :
1) The includes related to pthread (pthread.h, semaphores.h, bits/*.h)
are the one that belong to linuxThread includes not nptl ones,
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,
3) When linking in static mode, linuxThread implementation is chosen
and not NPTL one (wonder why on i386 and PPC at least),
4) There is no way to get NPTL threading using static linking mode.
This makes programme behaves differently when using static and
dynamic linking,
To clean up the mess, I think that :
1) When possible, the same thread implementation should be chosen
in dynamic and static mode. Most distrib indeed provide a nptl-dev
package for dynamic and static nptl thread usage,
2) As default linking is dynamic, default includes should be the
NPTL ones and not the linuxThreads ones,
3) If someone find a reason to not use NPTL in static mode, then
a diffrent package for static linuxThread code should be availiable
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).
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-rc1-bk6
Locale: [EMAIL PROTECTED], LC_CTYPE=en_IE (charmap=ISO-8859-15) (ignored:
LC_ALL set to [EMAIL PROTECTED])
Versions of packages libc6-dev depends on:
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
ii linux-kernel-headers 2.5.999-test7-bk-17 Linux Kernel Headers for developme
-- no debconf information
--- End Message ---
