Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Package: glibc Version: 2.3.6.ds1-4 Severity: serious Tags: patch Hi, the standard location for libraries on amd64 is (/usr)/lib64 but glibc is build for (/usr)/lib. In most cases this makes no difference but there are some: 1) Compatibility with other linux When you copy debians libc6 or static binaries to other linux systems then the location of plugins changes from /usr/lib to /usr/lib64 (/usr/lib/gconv/ becomes /usr/lib64/gconv/). 2) automatic conversion for multiarch The same thing happens here. The converter for multiarch deletes the (/usr)/lib64 link and changes (/usr)/lib to (/usr)/lib64 so the library does not conflict with its 32bit counterpart. Again /usr/lib/gconv/ becomes /usr/lib64/gconv/ and so on. The attached patch is a simple solution to the problem. Glibc on amd64 gets compiled for (/usr)/lib64 as the FHS/LSB specify for amd64 but before packaging it gets renamed to (/usr)/lib and (later) the lib64-lib links are put in place. This way it works everywhere. -- I set this to serious because it sort of violates a MUST directive in the FHS: http://www.debian.org/doc/packaging-manuals/fhs/fhs-2.3.html | /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) | | The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place | 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries | in /lib. It does not specificaly mention plugins but I hope you agree the same rational applies there for libc6. -- MfG Goswin -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-frosties-2 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) diff -u glibc-2.3.6.ds1/debian/rules.d/build.mk glibc-2.3.6.ds1/debian/rules.d/build.mk --- glibc-2.3.6.ds1/debian/rules.d/build.mk +++ glibc-2.3.6.ds1/debian/rules.d/build.mk @@ -124,6 +124,15 @@ tar zcf $(CURDIR)/debian/locales-all/usr/lib/locales-all/supported.tar.gz -C $(CURDIR)/debian/tmp-libc/usr/lib/locale .; \ fi + # Move lib64 to lib on amd64 + if [ $(curpass) = libc ] [ $(DEB_HOST_ARCH) = amd64 ]; then \ + find debian/tmp-$(curpass); \ + mkdir -p debian/tmp-$(curpass)/lib debian/tmp-$(curpass)/usr/lib; \ + mv debian/tmp-$(curpass)/lib64/* debian/tmp-$(curpass)/lib; \ + mv debian/tmp-$(curpass)/usr/lib64/* debian/tmp-$(curpass)/usr/lib; \ + rmdir debian/tmp-$(curpass)/lib64 debian/tmp-$(curpass)/usr/lib64; \ + fi + # Remove ld.so from optimized libraries if [ $(curpass) != libc ] [ $(call xx,configure_build) = $(call xx,configure_target) ]; then \ rm -f debian/tmp-$(curpass)/$(call xx,slibdir)/ld*.so* ; \ diff -u glibc-2.3.6.ds1/debian/sysdeps/amd64.mk glibc-2.3.6.ds1/debian/sysdeps/amd64.mk --- glibc-2.3.6.ds1/debian/sysdeps/amd64.mk +++ glibc-2.3.6.ds1/debian/sysdeps/amd64.mk @@ -2,8 +2,8 @@ libc_MIN_KERNEL_SUPPORTED = 2.6.0 libc_add-ons = nptl $(add-ons) libc_extra_cflags = -O3 -g1 -libc_slibdir = /lib -libc_libdir = /usr/lib +libc_slibdir = /lib64 +libc_libdir = /usr/lib64 libc_rtlddir = /lib64 # /lib64 and /usr/lib64 are provided by glibc instead base-files: #259302. diff -u glibc-2.3.6.ds1/debian/changelog glibc-2.3.6.ds1/debian/changelog --- glibc-2.3.6.ds1/debian/changelog +++ glibc-2.3.6.ds1/debian/changelog @@ -1,3 +1,11 @@ +glibc (2.3.6.ds1-4a0.ql.0.1) unstable; urgency=low + + * sysdeps/amd64.mk: Set libc_slibdir /lib64 and libc_libdir to /usr/lib64 + * rules.d/build.mk: on amd64 rename debian/tmp-libc/lib64 to lib +and debian/tmp-libc/usr/lib64 to lib + + -- Goswin von Brederlow [EMAIL PROTECTED] Mon, 11 Sep 2006 16:45:24 +0200 + glibc (2.3.6.ds1-4) unstable; urgency=low [ Aurelien Jarno ]
Bug#387459: [m68k] mathinlib.h previous definition
Package: libc6-dev Version: 2.3.6.ds1-4 Severity: important While building mcmcpack, we encountered the following error. | g++ -I/usr/share/R/include -I/usr/share/R/include | -DSCYTHE_COMPILE_DIRECT -DSCYTHE_NO_RANGE -fpic -g -O2 -c | distributions.cc -o distributions.o | distributions.cc: In function 'double trunc(double)': | distributions.cc:51: error: redefinition of 'double trunc(double)' | /usr/include/bits/mathinline.h:184: error: 'double trunc(double)' | previously defined here | make[1]: *** [distributions.o] Error 1 This bug is similar to the one fixed in 340871. The buildd log may be found at http://buildd.debian.org/fetch.php?pkg=mcmcpackver=0.7-2-1arch=m68kstamp=1157995262file=logas=raw Thanks, Stephen -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#387270: gnupg: segfaults when asking a passphrase
On Wed, 13 Sep 2006 09:12, Oohara Yuuma said: gnupg segfaults when it encrypts a file with a symmetric cipher: gpg --symmetric --armor copyright gpg: Segmentation fault caught ... exiting Segmentation fault FWIW, I can't replicate it with a stock 1.4.5 on Sid. What is the content of your gpg.conf? Salam-Shalom, Werner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387270: gnupg: segfaults when asking a passphrase
On Thu, 14 Sep 2006 17:54:59 +0200, Werner Koch [EMAIL PROTECTED] wrote: On Wed, 13 Sep 2006 09:12, Oohara Yuuma said: gnupg segfaults when it encrypts a file with a symmetric cipher: gpg --symmetric --armor copyright gpg: Segmentation fault caught ... exiting Segmentation fault FWIW, I can't replicate it with a stock 1.4.5 on Sid. What is the content of your gpg.conf? This was the bug of libc6 (#380504) which was fixed in libc6 2.3.6.ds1-2. -- Oohara Yuuma [EMAIL PROTECTED] Wee ki ra chs morto tes whou gauzewiga, en yehar omnis tes whou gyen. --- Raiden Freaks 2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387498: mips: system() hangs when compiled with -pg (gprof profiling(.
Package: libc6
Version: 2.3.6-16
Severity: serious
Greetings!
Is there any quick workaround here -- this is holding up
gcl/maxima/acl2/axiom.
Take care,
=
[EMAIL PROTECTED]:~$ cat t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
[EMAIL PROTECTED]:~$ echo $?
0
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
[1]+ Stopped ./t echo g
[EMAIL PROTECTED]:~$ cat t.c
int
main(int argc,char * argv[]) {return system(argv[1]);}
[EMAIL PROTECTED]:~$ [EMAIL PROTECTED]:~$ cc -g t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
g
[EMAIL PROTECTED]:~$ echo $?
0
[EMAIL PROTECTED]:~$ cc -g -pg t.c -o t
[EMAIL PROTECTED]:~$ ./t echo g
[1]+ Stopped ./t echo g
--
Camm Maguire[EMAIL PROTECTED]
==
The earth is but one country, and mankind its citizens. -- Baha'u'llah
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.4.25
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages libc6 depends on:
ii tzdata2006g-2Time Zone and Daylight Saving Time
libc6 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
Processing commands for [EMAIL PROTECTED]: severity 387446 normal Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS Severity set to `normal' from `serious' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387446: glibc: Please compile for (/usr)/lib64 on amd64 as per FHS
On Thu, Sep 14, 2006 at 01:28:24PM -0700, Steve Langasek wrote: severity 387446 normal thanks On Thu, Sep 14, 2006 at 02:05:01PM +0200, Goswin von Brederlow wrote: I set this to serious because it sort of violates a MUST directive in the FHS: Your changes also violate the FHS, as the system libraries should be in /lib. This is a known deviation from the FHS on amd64, and not one that is considered release-critical for etch. There is currently no way to do a plain amd64 distribution without violating the FHS. So I don't really want to make changes that probably have side effects just for violating the FHS another way. My opinion is that the FHS should be changed. Unfortunately nobody seems to read the FHS mailing list... That probably means that a change for this would not be accepted into etch, since fiddling library paths may have unexpected side-effects and glibc is already frozen. Agreed. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#387553: glibc nscd client code fails intermittently
Package: libc6 Version: 2.3.5 When using nscd, calls to functions like getgrgid() may fail intermittently whent the reply is large. This is because the entire reply may not yet be ready for reading in glibc's nscd client when __poll() first indicates that the socket is ready for reading. The functions __readall() and __readvall() in nscd/nscd_helper.c expect that the entire reply can be read immediately, since __poll() indicated that the socket was ready, but in reality this is not always the case - nscd may need to get scheduled again before more data will be available. The attached patch adds calls to __poll() inside the loops in these two functions when errno is EAGAIN to correct the problem. I have also sent the patch to the glibc developer list. The bug is present in glibc versions 2.3.5, 2.3.6, and 2.4, and probably all the way back to the introduction of nscd. nscd-client.patch.gz Description: GNU Zip compressed data
