2.3.4-3 in experimental
I've duploaded 2.3.4-3 into experimental. It's also available at:
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental
This version should have the complete fix for the optimized package upgrade
problem especially for i386 and sparc. The current glibc does _not_ handle
multiple libc hwcap packages correctly during their upgrade. If ld.so in
libc6 (2.3.4) is mixed with libc6.so in libc6-i686 (2.3.2.ds1-20), all
binaries are suddenly stopped. It's caused by the internal change between
ld.so and libc.so.6 during 2.3.3 development.
To fix this problem, I put the change into 2.3.4-3 that uses
/etc/ld.so.hwcappkgs to track the status of each hwcap packages (libc6 +
libc6-i686 on i386, and libc6 + libc6-sparcv9 + libc6-sparcv9b on sparc).
If hwcap package versions are not matched, /etc/ld.so.nohwcap is created
until all package versions are installed. I tested two types of package
transition as follows:
* 2.3.2.ds1-20 (sarge) = 2.3.4-3 (etch)
Sarge = etch transition. The following test scripts and special
packages can test this situation. It adds libc6-i586 package in order
to emulate sparc's two different optimized packages:
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-b/libc6{,-i686,-i586}*_i386.deb
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-b/log.b
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/transit.sh
If you try to test it, put my libc6 packages into the proper place on
chroot environment, then invoke as follows:
# ./transit.sh b /232ds1-20-dir /234-3-dir
* 2.3.2.ds1-100 = 2.3.4-3
This pattern emulates the future transition in etch (ex: 2.3.4 =
2.3.9x). 2.3.2.ds1-100 has the same ld.so.hwcappkgs script in 2.3.4-3,
but libraries are stayed as 2.3.2.ds1-20.
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-a/libc6{,-i686,-i586}*_i386.deb
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/test-a/log.a
If you want to test it, put my libc6 packages into the proper place, and
edit transit.sh, then invoke as follows:
# ./transit.sh a /232ds1-100-dir /234-3-dir
I tested them on i386 - I couldn't test on sparc because Ultra SPARC III
machine is required for checking libc6-sparcv9b. If you have Ultra SPARC
III, I hope you test with the following packages (or dists/experimental ftp
mirror):
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/libc6{,-sparcv9,-sparcv9b}*_sparc.deb
For developers:
The drawback of this method is: /etc/ld.so.nohwcap is left alone (== hwcap
is disabled) during the following scenarios:
1. Downgrade from 2.3.4-3 to 2.3.2.ds1-*. In this case, ld.so.nohwcap
keeps downgrade-to-old-glibc string. ld.so.nohwcap is not removed
until 2.3.4-3 is installed.
2. Mismatch version detection within hwcap packages. Ex: if libc6
(2.3.4-3) is installed, but libc6-i686 2.3.4-3 is kept away,
ld.so.nohwcap is not removed. When those versions are matched,
ld.so.nohwcap is removed. The problem is even tls libraries are not
loaded - so NPTL is disabled. But partial upgrade belongs to user's
responsibility, it's out of scope.
I thought this fix was also needed in 2.3.2.ds1-21, but finally I decided
not to put this fix into 2.3.2.ds1-21 because of the drawback 1.
If you have interested in the background of this mechanism theoretically,
you possibly need to look at the transition diagram of these packages:
* All version:
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash.pdf
* Separated graphics:
2.3.2.ds1-100 = 2.3.4-3 (i386 version):
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash-i686.png
2.3.2.ds1-100 = 2.3.4-3 (i386/sparc version):
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash-sparc.png
2.3.2.ds1-20 = 2.3.4-3 (i386/sparc version):
http://www.gotom.jp/~gotom/debian/glibc/2.3.4-3.experimental/opt-crash-232ds1.png
In this diagram, node represents each hwcap package combination. Edge
represents an action of package installation or removal. Note that we
don't need to care about some edge transitions because optimized packages
has Pre-Depends: libc6 (ex: we cannot install libc6-i686 2.3.2.ds1-20 when
libc6 2.3.4-3 is existed).
Regards,
-- gotom
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc - capaibility control mechanism
At Sun, 3 Apr 2005 12:24:38 +0200, Bastian Blank wrote: [1 text/plain; utf-8 (quoted-printable)] On Sat, Apr 02, 2005 at 09:37:54PM +0900, GOTO Masanori wrote: I think the simple shell script wrapper controlling HWCAP_MASK can achieve the original request by Bastian. No, it does not. You have to replace any binary with this wrapper, even /sbin/init. Hmm, I have not understood why you want to use such mechanism. What's the merit of your proposal? Which application are you focusing in this proposal? Okay, lets show some scenarios: 1. Enable specific optimizations: for example SSE. 2. Disable tls: run XenLinux or UML, both supports linux 2.6 but no TLS. 3. Disable i686 optimization: testing of the other libs. 4. Enable tls: RedHat shipped 2.4 kernels with TLS-Support. 1 and 4 can be done with LD_LIBRARY_PATH, as it is not critical. 3 can be done with LD_LIBRARY_PATH which pulls the unoptimized libs before the optimzed. 2 is missing, LD_ASSUME_KERNEL needs to be _always_ defined, it is not even possible to start a shell without. The current glibc defines a generic interface for 1 and 3 but noone is able to show me how to use it and my checks of the source showed that 3 is not able with the hwcap machanism. Note that 3 can be disabled on debian: /etc/ld.so.nohwcap. Tough it disables all hwcap mechanisms, we cannot select each hwcap bits currently. 2 and 4 is done via an explicit check for the kernel version. For me, it seems this issue mixes three different terms: (1) tls (controlled by LD_ASSUME_KERNEL) (2) processor platform AT_PLATFORM (no generic way to control) (3) processor capability AT_HWCAP (controlled by LD_HWCAP_MASK) Debian glibc i686 provides three libraries: /lib, /lib/tls, /lib/tls/i686/cmov. (3) can be hidden by controlling (2), and (2) can be hidden by controlling (1). Is it enough to fix your problem using /etc/ld.so.nohwcap, LD_ASSUME_KERNEL and LD_HWCAP_MASK? if you have experience to modify the code for specific architecture's capability to get performance improvement like HPC application, you would nod some parts of my previous mail. I have none, I only raised that as an example because people asked for a generic solution for that problem. We have even some library packages in the archive which provides such optimized libs, they use its one hack to enable optimized libs. Do you have any actual examples? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Processed: Re: Bug#295457: gcc-snapshot: FTBFS on amd64: /usr/include/pthread.h:655: error: array type has incomplete element type
Processing commands for [EMAIL PROTECTED]: tags 295457 fixed-upstream Bug#295457: gcc-snapshot: FTBFS on amd64: /usr/include/pthread.h:655: error: array type has incomplete element type There were no tags set. Tags added: fixed-upstream 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#295457: Processed: Re: Bug#295457: gcc-snapshot: FTBFS on amd64: /usr/include/pthread.h:655: error: array type has incomplete element type
tags 295457 fixed-upstream thanks /usr/include/pthread.h line 654-655 say: struct __jmp_buf_tag; extern int __sigsetjmp (struct __jmp_buf_tag __env[1], int __savemask) __THROW; Note that in 2.3.4 it's changed as follows: /* Function used in the macros. */ struct __jmp_buf_tag; extern int __sigsetjmp (struct __jmp_buf_tag *__env, int __savemask) __THROW; Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glibc - capaibility control mechanism
On Mon, Apr 04, 2005 at 03:42:25PM +0900, GOTO Masanori wrote: Note that 3 can be disabled on debian: /etc/ld.so.nohwcap. Tough it disables all hwcap mechanisms, we cannot select each hwcap bits currently. So it is unusable if there exists i386, i486 and i686. For me, it seems this issue mixes three different terms: (1) tls (controlled by LD_ASSUME_KERNEL) (2) processor platform AT_PLATFORM (no generic way to control) (3) processor capability AT_HWCAP (controlled by LD_HWCAP_MASK) No, this is one term, at least glibc internal; why is it exported via 3 or more different interfaces? Debian glibc i686 provides three libraries: /lib, /lib/tls, /lib/tls/i686/cmov. (3) can be hidden by controlling (2), and (2) can be hidden by controlling (1). Is it enough to fix your problem using /etc/ld.so.nohwcap, LD_ASSUME_KERNEL and LD_HWCAP_MASK? No, the environment is not persistent. We have even some library packages in the archive which provides such optimized libs, they use its one hack to enable optimized libs. Do you have any actual examples? atlas[23]-.* Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6 signature.asc Description: Digital signature
Re: glibc - capaibility control mechanism
At Mon, 4 Apr 2005 09:55:28 +0200, Bastian Blank wrote: [1 text/plain; utf-8 (quoted-printable)] On Mon, Apr 04, 2005 at 03:42:25PM +0900, GOTO Masanori wrote: Note that 3 can be disabled on debian: /etc/ld.so.nohwcap. Tough it disables all hwcap mechanisms, we cannot select each hwcap bits currently. So it is unusable if there exists i386, i486 and i686. Platform is just the current executing architecture. Even if there're three different platform libraries, they are not used at the same time. We have even some library packages in the archive which provides such optimized libs, they use its one hack to enable optimized libs. Do you have any actual examples? atlas[23]-.* Does atlas really need your proposal? Why not to add CPU detection and dlopen switch code in this library? Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: your mail
Processing commands for [EMAIL PROTECTED]: reassign 288710 libc6 Bug#288710: setfacl with many files at cmdline - Too many open files Bug reassigned from package `acl' to `libc6'. -- 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]
