[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[Fwd: libc6-dev: totally incoherent pthread related includes files for dynamic linking]



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: eric.valette@free.fr



--- 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: LANG=en_IE@euro, LC_CTYPE=en_IE (charmap=ISO-8859-15) (ignored: LC_ALL set to en_IE@euro)

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 ---

Reply to: