Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: libc-bin
Version: 2.10.2-6
I would like to override the standard libGL.so files by a private
library installed in a special directory. Problem: It seems that
the libraries in in /lib and /usr/lib have a higher priority than any
other directory. This is a severe restriction. Looking at ld.so(8)
I had the impression that /lib and /usr/lib are supposed to provide a
_default_ set of libraries to be overridden by ld.so.conf and
$LD_LIBRARY_PATH as needed;
:
:
The necessary shared libraries needed by the program are searched for in the
following order
o Using the environment variable LD_LIBRARY_PATH (LD_AOUT_LIBRARY_PATH
for a.out programs). Except if
the executable is a setuid/setgid binary, in which case it is ignored.
o From the cache file /etc/ld.so.cache which contains a compiled list of
candidate libraries previously
found in the augmented library path.
o In the default path /lib, and then /usr/lib.
:
:
Here is my setup:
% cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
% cat /etc/ld.so.conf.d/*.conf
/usr/lib/nvidia-current
/usr/lib32/nvidia-current
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
AFAICS this is Debian's default, except for the nvidia libs. Please note
that there is neither /usr/lib nor /lib included in this list.
ldd and strace show that the library is taken from the wrong directory.
Sample session:
% cat EOF /tmp/conftest.cpp
#include GL/gl.h
int main () { glBegin(GL_POINTS); return 0; }
EOF
% g++ /tmp/conftest.cpp -I/usr/include/nvidia-current -L/usr/lib/nvidia-current
-lGL -o /tmp/conftest
% ldd /tmp/conftest
linux-vdso.so.1 = (0x7fff217ff000)
libGL.so.1 = /usr/lib/libGL.so.1 (0x7f4673b5f000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f467384b000)
:
:
%
% file -L /usr/lib/libGL.so.1 /usr/lib/nvidia-current/libGL.so.1
/usr/lib/libGL.so.1:ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped
/usr/lib/nvidia-current/libGL.so.1: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, stripped
Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuTvM0ACgkQUTlbRTxpHjfWbwCcD4pDDI6BwI3v1mAz01AIAe1m
ZBcAn34Pw3/iSKtsskC8duMc1XNRtCcK
=B/XD
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4b93bccd.7070...@darkharri.de
Bug#572746: libm: sinf/cosf performance is awful on amd64
On Sat, Mar 06, 2010 at 11:42:51AM +0100, Jerome Vizcaino wrote: Package: libc6 Version: 2.10.2-6 Severity: normal Hi, After many tests and research I've come to the conclusion that the float variants of sin/cos (and maybe others) are anormaly slow Debian amd64. The performance loss is really impressive (around 8 to 9 times slower). I've attached the prog used to make my experiments and used it in the following cases. + Lenny-amd64: sinf/cosf is really slow + Lenny-i386: float performance is ok (faster than the cos/sin using double) + Sid-amd64: sinf/cosf slow + Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is OK. On amd64, only sincos has an optimized version, sincosf is using the generic C implementation. On i386, there are optimized version of both sincos and sincosf + OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, the tests run fine ! = The problem is not compiler related. There seems to be a problem with the way libm is compiled for the amd64 architecture on Debian. This is why the OpenSuse test was run: the problem is somewhere in the compile chain or debian specific patches. The problem is clearly not Debian specific, and is also present upstream. OpenSuse is probably using a patch to workaround the problem. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100307151708.ga...@hall.aurel32.net
Bug#572895: ldconfig issue: priority of /lib and /usr/lib is too high
On Sun, Mar 07, 2010 at 03:48:45PM +0100, Harald Dunkel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Package: libc-bin
Version: 2.10.2-6
I would like to override the standard libGL.so files by a private
library installed in a special directory. Problem: It seems that
the libraries in in /lib and /usr/lib have a higher priority than any
other directory. This is a severe restriction. Looking at ld.so(8)
I had the impression that /lib and /usr/lib are supposed to provide a
_default_ set of libraries to be overridden by ld.so.conf and
$LD_LIBRARY_PATH as needed;
:
:
The necessary shared libraries needed by the program are searched for in the
following order
o Using the environment variable LD_LIBRARY_PATH
(LD_AOUT_LIBRARY_PATH for a.out programs). Except if
the executable is a setuid/setgid binary, in which case it is ignored.
o From the cache file /etc/ld.so.cache which contains a compiled list of
candidate libraries previously
found in the augmented library path.
o In the default path /lib, and then /usr/lib.
:
:
Here is my setup:
% cat /etc/ld.so.conf
include /etc/ld.so.conf.d/*.conf
% cat /etc/ld.so.conf.d/*.conf
/usr/lib/nvidia-current
/usr/lib32/nvidia-current
# libc default configuration
/usr/local/lib
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
AFAICS this is Debian's default, except for the nvidia libs. Please note
that there is neither /usr/lib nor /lib included in this list.
ldd and strace show that the library is taken from the wrong directory.
Sample session:
% cat EOF /tmp/conftest.cpp
#include GL/gl.h
int main () { glBegin(GL_POINTS); return 0; }
EOF
% g++ /tmp/conftest.cpp -I/usr/include/nvidia-current
-L/usr/lib/nvidia-current -lGL -o /tmp/conftest
% ldd /tmp/conftest
linux-vdso.so.1 = (0x7fff217ff000)
libGL.so.1 = /usr/lib/libGL.so.1 (0x7f4673b5f000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f467384b000)
:
:
%
% file -L /usr/lib/libGL.so.1 /usr/lib/nvidia-current/libGL.so.1
/usr/lib/libGL.so.1:ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, for GNU/Linux 2.4.20, stripped
/usr/lib/nvidia-current/libGL.so.1: ELF 64-bit LSB shared object, x86-64,
version 1 (SYSV), dynamically linked, stripped
Have you run ldconfig after doing the change? What's the output of
ldconfig -p | grep libGL.so.1?
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100307152231.gb...@hall.aurel32.net
Bug#572746: libm: sinf/cosf performance is awful on amd64
On Sun, Mar 07, 2010 at 04:17:08PM +0100, Aurelien Jarno wrote: On Sat, Mar 06, 2010 at 11:42:51AM +0100, Jerome Vizcaino wrote: Package: libc6 Version: 2.10.2-6 Severity: normal Hi, After many tests and research I've come to the conclusion that the float variants of sin/cos (and maybe others) are anormaly slow Debian amd64. The performance loss is really impressive (around 8 to 9 times slower). I've attached the prog used to make my experiments and used it in the following cases. + Lenny-amd64: sinf/cosf is really slow + Lenny-i386: float performance is ok (faster than the cos/sin using double) + Sid-amd64: sinf/cosf slow + Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is OK. On amd64, only sincos has an optimized version, sincosf is using the generic C implementation. On i386, there are optimized version of both sincos and sincosf + OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, the tests run fine ! = The problem is not compiler related. There seems to be a problem with the way libm is compiled for the amd64 architecture on Debian. This is why the OpenSuse test was run: the problem is somewhere in the compile chain or debian specific patches. The problem is clearly not Debian specific, and is also present upstream. OpenSuse is probably using a patch to workaround the problem. This is confirmed, there using an AMD version of the libm library on x86_64, still coded in C for the sincosf function. A quick an dirty implementation of sincosf in x86_64 assembly gives me a speed around 4% slower than sincos. What kind of performance ratio do you get on SuSe? The solution seems to write each *f function in x86_64 assembly, but that'll probably take time. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100307161759.gc...@hall.aurel32.net
Bug#572746: libm: sinf/cosf performance is awful on amd64
Hi, I could not say for sure the difference between sin and sinf (for example) on Suse but the performance ratio I had on 32 bits, stayed the same on 64 bits. This is why I was surprised to get impressive slowness when moving to debian :( Thanks for pointing out the Suse patch : as we only have Suse or Debian at work I could not do more comparisons. How about including patches from OpenSuse ? Is it possible as a quick workaround? Thanks for your help. Jerome On Sunday 07 March 2010, you wrote: On Sun, Mar 07, 2010 at 04:17:08PM +0100, Aurelien Jarno wrote: On Sat, Mar 06, 2010 at 11:42:51AM +0100, Jerome Vizcaino wrote: Package: libc6 Version: 2.10.2-6 Severity: normal Hi, After many tests and research I've come to the conclusion that the float variants of sin/cos (and maybe others) are anormaly slow Debian amd64. The performance loss is really impressive (around 8 to 9 times slower). I've attached the prog used to make my experiments and used it in the following cases. + Lenny-amd64: sinf/cosf is really slow + Lenny-i386: float performance is ok (faster than the cos/sin using double) + Sid-amd64: sinf/cosf slow + Lenny-amd64 using lenny-i386 binary and 32bits libs: float performance is OK. On amd64, only sincos has an optimized version, sincosf is using the generic C implementation. On i386, there are optimized version of both sincos and sincosf + OpenSuse 64 bits (10.3 and 11.1): using the binary compiled on lenny-amd64, the tests run fine ! = The problem is not compiler related. There seems to be a problem with the way libm is compiled for the amd64 architecture on Debian. This is why the OpenSuse test was run: the problem is somewhere in the compile chain or debian specific patches. The problem is clearly not Debian specific, and is also present upstream. OpenSuse is probably using a patch to workaround the problem. This is confirmed, there using an AMD version of the libm library on x86_64, still coded in C for the sincosf function. A quick an dirty implementation of sincosf in x86_64 assembly gives me a speed around 4% slower than sincos. What kind of performance ratio do you get on SuSe? The solution seems to write each *f function in x86_64 assembly, but that'll probably take time. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003071943.46266.vizcaino_jer...@yahoo.fr
Bug#572746: libm: sinf/cosf performance is awful on amd64
On Sun, Mar 07, 2010 at 07:43:46PM +0100, Jerome Vizcaino wrote: Hi, I could not say for sure the difference between sin and sinf (for example) on Suse but the performance ratio I had on 32 bits, stayed the same on 64 bits. This is why I was surprised to get impressive slowness when moving to debian :( Thanks for pointing out the Suse patch : as we only have Suse or Debian at work I could not do more comparisons. How about including patches from OpenSuse ? Is it possible as a quick workaround? The patches from OpenSuse are ugly and very invasive, and they do not seem to include the recent errno changes for C99 compliance (though I haven't tested them). I am not really sure we want that. I have started to rewrite part of the functions in assembly. While this new assembly code behaves correctly with your testcase, it is twice slower than the current version when using normal arguments. I have modified a bit your code to stay within a reasonable range of arguments, and also test the l version of the functions. Here is the result with the original code (using C code for the f version): | Testing 1000 sinf, cosf and tanf... Result: 19764686.00, Duration: 0.516700 sec | Testing 1000 sin, cos and tan (with float args)... Result: 19764686.00, Duration: 1.056214 sec | Testing 1000 sinl, cosl and tanl (with float args)... Result: 19764686.00, Duration: 1.089871 sec Here is the result with assembly code instead (using the FPU instructions), I get instead: | Testing 1000 sinf, cosf and tanf... Result: 19764686.00, Duration: 1.010248 sec | Testing 1000 sin, cos and tan (with float args)... Result: 19764686.00, Duration: 1.055434 sec | Testing 1000 sinl, cosl and tanl (with float args)... Result: 19764686.00, Duration: 1.095374 sec As I expect most codes to use values between -2pi and 2pi, I am not really sure we should change the current code. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100307210105.ge...@hall.aurel32.net
Bug#572746: libm: sinf/cosf performance is awful on amd64
On Mon, Mar 08, 2010 at 12:17:41AM +0100, Jerome Vizcaino wrote: Ok about the patches : there had to be a reason for those not to be merged upstream. Also I think they have never been submitted upstream. They are from 2002... Some of my co-workers noticed the performance improvement when binding values between -pi and pi but the thing is, this kind of trick do not need to be applied when on 32 bits systems... Libm's behavior is not really arch-proof in terms of performance which is a bit confusing (and I would expect 64 bit being better than 32 bits when dealing with maths... :( cosf/sinf is actually twice faster on 64-bit than on 32-bit in normal cases, but can be a lot slower in the cases that concern you. Have you tried pushing your code upstream ? Maybe this would be useful for future versions. It's currently not clean enough to be send upstream. I'll try to send it upstream, but I don't have to much hope. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100307232342.gg...@hall.aurel32.net
Bug#572746: libm: sinf/cosf performance is awful on amd64
Ok about the patches : there had to be a reason for those not to be merged upstream. Some of my co-workers noticed the performance improvement when binding values between -pi and pi but the thing is, this kind of trick do not need to be applied when on 32 bits systems... Libm's behavior is not really arch-proof in terms of performance which is a bit confusing (and I would expect 64 bit being better than 32 bits when dealing with maths... :( Have you tried pushing your code upstream ? Maybe this would be useful for future versions. Thanks for your help Jerome On Sunday 07 March 2010, Aurelien Jarno wrote: On Sun, Mar 07, 2010 at 07:43:46PM +0100, Jerome Vizcaino wrote: Hi, I could not say for sure the difference between sin and sinf (for example) on Suse but the performance ratio I had on 32 bits, stayed the same on 64 bits. This is why I was surprised to get impressive slowness when moving to debian :( Thanks for pointing out the Suse patch : as we only have Suse or Debian at work I could not do more comparisons. How about including patches from OpenSuse ? Is it possible as a quick workaround? The patches from OpenSuse are ugly and very invasive, and they do not seem to include the recent errno changes for C99 compliance (though I haven't tested them). I am not really sure we want that. I have started to rewrite part of the functions in assembly. While this new assembly code behaves correctly with your testcase, it is twice slower than the current version when using normal arguments. I have modified a bit your code to stay within a reasonable range of arguments, and also test the l version of the functions. Here is the result with the original code (using C code for the f version): | Testing 1000 sinf, cosf and tanf... Result: 19764686.00, | Duration: 0.516700 sec Testing 1000 sin, cos and tan (with float | args)... Result: 19764686.00, Duration: 1.056214 sec Testing 1000 | sinl, cosl and tanl (with float args)... Result: 19764686.00, | Duration: 1.089871 sec Here is the result with assembly code instead (using the FPU instructions), I get instead: | Testing 1000 sinf, cosf and tanf... Result: 19764686.00, | Duration: 1.010248 sec Testing 1000 sin, cos and tan (with float | args)... Result: 19764686.00, Duration: 1.055434 sec Testing 1000 | sinl, cosl and tanl (with float args)... Result: 19764686.00, | Duration: 1.095374 sec As I expect most codes to use values between -2pi and 2pi, I am not really sure we should change the current code. -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201003080017.41964.vizcaino_jer...@yahoo.fr
r4220 - in glibc-package/trunk/debian: . patches patches/kfreebsd
Author: ps-guest
Date: 2010-03-08 01:54:57 + (Mon, 08 Mar 2010)
New Revision: 4220
Added:
glibc-package/trunk/debian/patches/kfreebsd/local-ftw.diff
Modified:
glibc-package/trunk/debian/changelog
glibc-package/trunk/debian/patches/kfreebsd/local-sysdeps.diff
glibc-package/trunk/debian/patches/series.kfreebsd-amd64
glibc-package/trunk/debian/patches/series.kfreebsd-i386
Log:
kfreebsd/local-sysdeps.diff: update to revision 2994
re-enable kfreebsd/local-ftw.diff
Modified: glibc-package/trunk/debian/changelog
===
--- glibc-package/trunk/debian/changelog2010-03-05 21:42:48 UTC (rev
4219)
+++ glibc-package/trunk/debian/changelog2010-03-08 01:54:57 UTC (rev
4220)
@@ -30,10 +30,7 @@
* Fix lang_ab field in es_CR locales. Closes: #571755.
[ Petr Salinger]
- * kfreebsd/local-sysdeps.diff: update to revision 2986 (from glibc-bsd).
- * Drop kfreebsd/local-ftw.diff, use *at functions as other architectures,
-the 8.0 kernel supports them as native, under previous kernels we have
-limited emulation.
+ * kfreebsd/local-sysdeps.diff: update to revision 2994 (from glibc-bsd).
-- Aurelien Jarno aure...@debian.org Sun, 28 Feb 2010 11:27:56 +0100
Added: glibc-package/trunk/debian/patches/kfreebsd/local-ftw.diff
===
--- glibc-package/trunk/debian/patches/kfreebsd/local-ftw.diff
(rev 0)
+++ glibc-package/trunk/debian/patches/kfreebsd/local-ftw.diff 2010-03-08
01:54:57 UTC (rev 4220)
@@ -0,0 +1,124 @@
+
+disable usage of unimplemented *at functions
+revert to previous behaviour, inspired by
+ http://sourceware.org/ml/glibc-cvs/2006-q1/msg00636.html
+
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/io/ftw.c.diff?cvsroot=glibcr1=1.50r2=1.51
+
+
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/posix/glob.c.diff?cvsroot=glibcr1=1.77r2=1.78
+
+---
+ io/ftw.c |6 ++
+ posix/glob.c | 31 +++
+ 2 files changed, 9 insertions(+), 28 deletions(-)
+
+--- a/io/ftw.c
b/io/ftw.c
+@@ -338,6 +338,7 @@
+ {
+ assert (data-dirstreams[data-actdir] == NULL);
+
++#if 0
+ if (dfdp != NULL *dfdp != -1)
+ {
+ int fd = openat64_not_cancel_3 (*dfdp, data-dirbuf + data-ftw.base,
+@@ -347,6 +348,7 @@
+ close_not_cancel_no_status (fd);
+ }
+ else
++#endif
+ {
+ const char *name;
+
+@@ -410,10 +412,12 @@
+ *((char *) __mempcpy (data-dirbuf + data-ftw.base, name, namlen)) = '\0';
+
+ int statres;
++#if 0
+ if (dir-streamfd != -1)
+ statres = FXSTATAT (_STAT_VER, dir-streamfd, name, st,
+ (data-flags FTW_PHYS) ? AT_SYMLINK_NOFOLLOW : 0);
+ else
++#endif
+ {
+ if ((data-flags FTW_CHDIR) == 0)
+ name = data-dirbuf;
+@@ -433,10 +437,12 @@
+ flag = FTW_SLN;
+ else
+ {
++#if 0
+ if (dir-streamfd != -1)
+ statres = FXSTATAT (_STAT_VER, dir-streamfd, name, st,
+ AT_SYMLINK_NOFOLLOW);
+ else
++#endif
+ statres = LXSTAT (_STAT_VER, name, st);
+ if (statres == 0 S_ISLNK (st.st_mode))
+ flag = FTW_SLN;
+--- a/posix/glob.c
b/posix/glob.c
+@@ -1222,42 +1222,21 @@
+allocated with alloca to be recycled. */
+ #if !defined _LIBC || !defined GLOB_ONLY_P
+ static int
+-__attribute_noinline__
+-link_exists2_p (const char *dir, size_t dirlen, const char *fname,
+- glob_t *pglob
+-# ifndef _LIBC
+- , int flags
+-# endif
+- )
++link_exists_p (const char *dir, size_t dirlen, const char *fname,
++ glob_t *pglob, int flags)
+ {
+ size_t fnamelen = strlen (fname);
+ char *fullname = (char *) __alloca (dirlen + 1 + fnamelen + 1);
+ struct stat st;
+-# ifndef _LIBC
+ struct_stat64 st64;
+-# endif
+
+ mempcpy (mempcpy (mempcpy (fullname, dir, dirlen), /, 1),
+ fname, fnamelen + 1);
+
+-# ifdef _LIBC
+- return (*pglob-gl_stat) (fullname, st) == 0;
+-# else
+ return ((__builtin_expect (flags GLOB_ALTDIRFUNC, 0)
+ ? (*pglob-gl_stat) (fullname, st)
+ : __stat64 (fullname, st64)) == 0);
+-# endif
+ }
+-# ifdef _LIBC
+-# define link_exists_p(dfd, dirname, dirnamelen, fname, pglob, flags) \
+- (__builtin_expect (flags GLOB_ALTDIRFUNC, 0)\
+- ? link_exists2_p (dirname, dirnamelen, fname, pglob)
\
+- : ({ struct stat64 st64; \
+- __fxstatat64 (_STAT_VER, dfd, fname, st64, 0) == 0; }))
+-# else
+-# define link_exists_p(dfd, dirname, dirnamelen, fname, pglob, flags) \
+- link_exists2_p (dirname, dirnamelen, fname, pglob, flags)
+-# endif
+ #endif
+
+
+@@ -1332,10 +1311,6 @@
+ }
+ else
+ {
+-#ifdef _LIBC
+-int dfd = (__builtin_expect
Processed: Re: LinuxThreads manual pages
Processing commands for cont...@bugs.debian.org: clone 460637 -1 Bug#460637: glibc-doc: Manual pages are outdated for NPTL Bug 460637 cloned as bug 572996. retitle 460637 manpages-dev: Port over whatever is useful from LinuxThreads pages Bug #460637 [glibc-doc] glibc-doc: Manual pages are outdated for NPTL Changed Bug title to 'manpages-dev: Port over whatever is useful from LinuxThreads pages' from 'glibc-doc: Manual pages are outdated for NPTL' severity 460637 wishlist Bug #460637 [glibc-doc] manpages-dev: Port over whatever is useful from LinuxThreads pages Severity set to 'wishlist' from 'normal' reassign 460637 manpages-dev Bug #460637 [glibc-doc] manpages-dev: Port over whatever is useful from LinuxThreads pages Bug reassigned from package 'glibc-doc' to 'manpages-dev'. Bug No longer marked as found in versions glibc/2.7-6. retitle -1 Please remove outdated LinuxThreads manpages Bug #572996 [glibc-doc] glibc-doc: Manual pages are outdated for NPTL Changed Bug title to 'Please remove outdated LinuxThreads manpages' from 'glibc-doc: Manual pages are outdated for NPTL' forcemerge 572716 -1 Bug#572716: glibc-doc: please stop providing man pages for pthread_kill(3) et al Bug#572996: Please remove outdated LinuxThreads manpages Forcibly Merged 572716 572996. severity -1 minor Bug #572996 [glibc-doc] Please remove outdated LinuxThreads manpages Bug #572716 [glibc-doc] glibc-doc: please stop providing man pages for pthread_kill(3) et al Severity set to 'minor' from 'wishlist' Severity set to 'minor' from 'wishlist' block -1 by 519781 Bug #572996 [glibc-doc] Please remove outdated LinuxThreads manpages Bug #572716 [glibc-doc] glibc-doc: please stop providing man pages for pthread_kill(3) et al Was not blocked by any bugs. Added blocking bug(s) of 572996: 562148, 519781, 562150, and 562149 Was not blocked by any bugs. Added blocking bug(s) of 572716: 562148, 519781, 562150, and 562149 thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.126802660517430.transcr...@bugs.debian.org
Bug#460637: LinuxThreads manual pages
clone 460637 -1 retitle 460637 manpages-dev: Port over whatever is useful from LinuxThreads pages severity 460637 wishlist reassign 460637 manpages-dev retitle -1 Please remove outdated LinuxThreads manpages forcemerge 572716 -1 severity -1 minor block -1 by 519781 thanks Jonathan Nieder wrote: Josef Spillner wrote: The man pages are LinuxThreads-specific, even though the default implementation of pthreads is NPTL nowadays. Some library calls such as pthread_mutexattr_setpshared are missing, and some of the limitations (such as using inter-process mutex locking), options and other peculiarities also differ. Unfortunately I think that the docs are outdated upstream as well Indeed, the LinuxThreads man pages are not even maintained upstream any more AFAICT. My suggestion would be to copy over any information and text that applies for NPTL to the man-pages project, and once the man-pages versions are deemed suitable (or maybe right away), get the Debian glibc-doc package to stop shipping these files and manpages-dev to start. So splitting the bug in two: - Since the LinuxThreads man pages tend to be nice though outdated, I will be working as time permits to copy what is still applicable to man-pages. mtk seems to be okay with this plan, which is nice. See [1] for details on how to help out. - The pages in man-pages are usable and maintained, and I think we should ship them. This requires coordination between the two packages. Actually, manpages-dev should be changed first (with Replaces: glibc-doc, this requires no action by the glibc maintainers). [1] http://bugs.debian.org/460637 -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100308053636.ga22...@progeny.tock
