When building glibc 2.3.5 with nptl support (USE=nptl), both the linuxthread and nptl compiles without any errors, but everything run after that will cause a segfault if you don't use the LD_ASSUME_KERNEL=2.4.1 infront of your commands. Reproducible: Always Steps to Reproduce: 1. set ACCEPT_KEYWORDS="~ppc" 2. set USE="nptl" 3. emerge glibc Actual Results: The nptl version of glibc causes segfaults for all commands. Expected Results: The commands should be executed like they are done with glibc 2.3.4. Portage 2.0.51.21-r1 (default-linux/ppc/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20041102-r1, 2.6.10-pegasos-r3 ppc) ================================================================= System uname: 2.6.10-pegasos-r3 ppc 7447/7457, altivec supported Gentoo Base System version 1.4.16 dev-lang/python: 2.3.4-r1 sys-apps/sandbox: 1.2.7 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.4 sys-devel/binutils: 2.15.90.0.3-r4 sys-devel/libtool: 1.5.16 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=7400 -mtune=7400 -maltivec -mabi=altivec -pipe -fno-strict-aliasing" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=7400 -mtune=7400 -maltivec -mabi=altivec -pipe -fno-strict-aliasing" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo/ ftp://trumpetti.atm.tut.fi/gentoo/ ftp://ftp.du.se/pub/os/gentoo ftp://mirror.pudas.net/gentoo http://ftp.linux.ee/pub/gentoo/distfiles/ ftp://ftp.linux.ee/pub/gentoo/distfiles/ ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo" LANG="en_US" LC_ALL="en_US" LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/servers/portage" SYNC="rsync://kotiaho.net/gentoo-portage" USE="ppc X alsa altivec berkdb bitmap-fonts cdr crypt cups dvd dvdr emacs emboss ffmpeg fortran gif gnome gphoto2 gpm gtk gtk2 ipv6 jpeg kde lame libwww mbox motif mp3 mpeg mysql ncurses nls nocd nptl oggvorbis opengl pam pdflib perl png python qt readline sdl spell ssl tcpd transcode truetype truetype-fonts type1-fonts udev unicode usb xft xml2 xprint xv xvid zlib linguas_en_GB userland_GNU kernel_linux elibc_glibc"
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.
