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: