Bug#279423: libc6-dev: totally incoherent pthread related includes files for dynamic linking
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.
> 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,
nptl-dev provides headers and static libraries for NPTL, which we don't
provide at all. In fact most distributions do exactly the same as
Debian with their default headers and dynamic libraries.
> 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.
> 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?
We can revisit these choices after sarge.
> 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.
--
Daniel Jacobowitz
Reply to: