tags 270745 fixed-in-experimental thanks At Sat, 25 Sep 2004 11:00:11 -0300, Cesar Eduardo Barros wrote: > > > It might not get any benefit from using > > > /lib/tls/i686/cmov/libc-2.3.2.so, but as you can see it's being used. > > > > > > When running libc6.postinst, the new libc6-i686 wasn't yet unpacked, and > > > so when libc6.postist restarted init, it used the new ld-2.3.2.so but > > > the old /lib/tls/i686/cmov/libc-2.3.2.so (since nothing on init > > > prevented it from using the i686 libc). > > > > No. During configuration, /etc/ld.so.nohwcap is created; libc6-i686 > > libraries should not be used. Check reinstall libc6 and libc6-i686 > > with lsof. > > Yes, it is created. However, it is removed *before* init (and the rest > of the daemons) is restarted, and so init gets the i686 libraries. > > ld.so.nohwcap is emptied at line 178, just before the daemons are > restarted. init is restarted near the end of the script.
Yes, your observation is correct. > A fix for this bug might be to move the emptying of ld.so.nohwcap to the > end of the postinst (after init and the daemons were restarted), or even > to the postinst of libc6-i686 (so while there is a version skew between > libc6 and libc6-i686, libc6-i686 would not be used; ld.so.nohwcap could > be emptied by both postinsts only if both versions are the same). From experimental glibc 2.3.4-2 or -3, /etc/ld.so.nohwcap is not removed until the same libc6-i686/libc6 version is installed. I think this bug should be fixed in experimental. I'll close it when new glibc will be put into unstable. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
