Summary: | glibc 2.3.5 with nptl and linuxthread generates a none working nptl version. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | J.O. Aho <bugs-gentoo> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | mail, panard, ppc |
Priority: | Highest | ||
Version: | 2005.0 | ||
Hardware: | PPC | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | ld.so fix |
Description
J.O. Aho
2005-05-16 07:49:12 UTC
Forgot to mention that this is a quite fresh Gentoo 2005.0 install, but had this problem on my previous Gentoo LinuxPPC install which I did wipe out due glibc didn't work. looks like the problem is in ldconfig and the ld.so.cache generated. Removing it seems to fix the problem, regenerating it make it appear again. As a workaround, compile glibc with nptl nptlonly or -ntpl -nptlonly until this problem is resolved. Here's an update: It turns out that we get segfaults when the following conditions are met: 1. ld.so.cache is present 2. the binary we are attempting to run is linked against *only* /lib/tls/libc.so.6 and nothing else in /lib/tls Removing /etc/ld.so.cache will prevent segfaults. If a binary is linked against libc.so.6 *and* something else from /lib/tls (such as libm or libpthreads) it will still work with /etc/ld.so.cache present. Replacing ld.so.1 with a copy from a good compile of glibc-2.3.4.20041102 fixes the problem. I'm currently trying to figure out what changed between the two versions and will provide a follow up if I figure anything out. Okey, it's good to see that there is a bit progress here, I don't have the option to make only nptl or linuxthreads and would like to install gcc 4.0.1 to get the build in altivec optimization to see if boinc will increase in preformance or not. Heared that you guys are discussing this matter without any results on solving this problem. Noticed that glibc 2.3.5 has ben made stable on x86, you guys know if this problem is there too or if it's only PPC? And no, I can't point out a program that don't work with nptl, but do have netscape 4 (PLD version) installed, which could be one that needs linuxthreads. We've decided to force either nptl or linuxthreads, there's not much else we can do since nobody has come up with a solution and it seems gentoo specific. glibc-2.3.5-r2 is now stable. Well this looks like the place to put this. I recently upgraded to glibc-2.3.5 (I reckon that's probably the cause). Since then, whenever I have both tvtime and boinc/setiathome running, as soon as *anything* else taxes the CPU, my entire system goes down. This can be something as small as copying a big file or loading a complex website in Firefox - compiling anything doesn't stand a chance. It's OK to do these things if I don't have tvtime running, or if I shutdown boinc. In the interests of investigation I upgraded to a newer version of tvtime, so I don't reckon it's that. I think it's the combination of glibc-2.3.5, TV watching and boinc's feature to step out of the way whenever anything else wants the CPU that's combining to cause this system crash. I'm currently using: glibc-2.3.5-r2 with NPTL tvtime-1.0.1 (was 0.9.15) gentoo-sources-2.6.14 Just to note, the problem persists in glibc-2.3.6. I discovered you're having the same problems I am with my distribution. The good news is that there is a very simple solution: since you're building glibc twice (first with linuxthreads, second with nptl) just overwrite the linuxthreads /lib/ld-2.3.5.so with /lib/tls/ld-2.3.5.so and it works fine in both instances. I've tested this w/Nevaeh Linux running glibc-2.3.5 compiled with gcc-3.4.4 and binutils-2.16.1 on an IBM p5-570 (POWER5 processor). Before overwriting /lib/ld-2.3.5.so the following test failed: echo 'int main() { return 0; }' > test.c gcc test.c ./a.out (segmentation fault) LD_ASSUME_KERNEL=2.4.1 ./a.out (success) After overwriting /lib/ld-2.3.5.so the above test succeeds, and ldd shows the proper library selected depending on the value LD_ASSUME_KERNEL. --Arthur Corliss acorliss@nevaeh-linux.org Created attachment 76792 [details, diff]
ld.so fix
You're absolutely right! :) Thanks for the info.
Here's a patch that does exactly that. If we could have a few testers, that would be great.
I'll build some G4 testing stages with the patch applied. G4-stages built. A test given by JoseJX in a chroot was good: elrohir / # LD_ASSUME_KERNEL=2.4.1 ldd /bin/grep libc.so.6 => /lib/libc.so.6 (0x0feb2000) /lib/ld.so.1 (0x30000000) elrohir / # ldd /bin/grep libc.so.6 => /lib/tls/libc.so.6 (0x0feb1000) /lib/ld.so.1 (0x30000000) elrohir / # This workaround has been added to the glibc-2.3.5-r3 and glibc-2.3.6-r2 ebuilds. Please reopen if you have a problem. |