pegasos chris # emerge -pv perl These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] dev-lang/perl-5.8.6-r4 [5.8.6-r1] +berkdb +debug +doc +gdbm +ithreads -perlsuid 0 kB Total size of downloads: 0 kB pegasos chris # The following occurs: CCCMD = powerpc-unknown-linux-gnu-gcc -DPERL_CORE -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer -g -Wall rm -f libperl.a /usr/bin/ar rcu libperl.a perl.o gv.o toke.o perly.o op.o pad.o regcomp.o dump.o util.o mg.o reentr.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o locale.o pp_pack.o pp_sort.o `sh cflags "optimize='-mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer -g'" opmini.o` -fPIC -DPERL_EXTERNAL_GLOB opmini.c CCCMD = powerpc-unknown-linux-gnu-gcc -DPERL_CORE -c -D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer -g -Wall powerpc-unknown-linux-gnu-gcc -L/usr/local/lib -o miniperl \ miniperlmain.o opmini.o libperl.a -lpthread -lnsl -ldl -lm -lcrypt -lutil -lc ./miniperl -w -Ilib -MExporter -e '<?>' || make minitest /bin/sh: line 1: 23529 Segmentation fault ./miniperl -w -Ilib -MExporter -e '<?>' make[1]: Entering directory `/var/tmp/portage/perl-5.8.6-r4/work/perl-5.8.6' cp ext/re/re.pm ext/re/re.tmp && sh mv-if-diff ext/re/re.tmp lib/re.pm make[2]: Entering directory `/var/tmp/portage/perl-5.8.6-r4/work/perl-5.8.6' ./miniperl -Ilib configpm configpm.tmp make[2]: *** [lib/Config.pm] Segmentation fault make[2]: Leaving directory `/var/tmp/portage/perl-5.8.6-r4/work/perl-5.8.6' make[1]: [minitest.prep] Error 2 (ignored) You may see some irrelevant test failures if you have been unable to build lib/Config.pm, lib/lib.pm or the Unicode data files. cd t && (rm -f perl; /bin/ln -s ../miniperl perl) \ && ./perl TEST -minitest base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t uni/*.t </dev/tty /bin/sh: line 1: 23548 Segmentation fault ./perl TEST -minitest base/*.t comp/*.t cmd/*.t run/*.t io/*.t op/*.t uni/*.t </dev/tty make[1]: [minitest] Error 139 (ignored) make[1]: Leaving directory `/var/tmp/portage/perl-5.8.6-r4/work/perl-5.8.6' make: [extra.pods] Error 1 (ignored) ./miniperl -Ilib configpm configpm.tmp make: *** [lib/Config.pm] Segmentation fault !!! ERROR: dev-lang/perl-5.8.6-r4 failed. !!! Function src_compile, Line 247, Exitcode 2 !!! Unable to make !!! If you need support, post the topmost build error, NOT this status message. pegasos chris # ppc herd: can one of you that has a pegasos verify this as well?
seperated emerge --info to make it a bit more readable. Portage 2.0.51.22-r1 (default-linux/ppc/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.20041102-r0, 2.6.9-pegasos-r4 ppc) ================================================================= System uname: 2.6.9-pegasos-r4 ppc 7447/7457, altivec supported Gentoo Base System version 1.6.8 dev-lang/python: 2.3.4, 2.4 sys-apps/sandbox: 1.2.9 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9, 1.8.5-r2, 1.9.3 sys-devel/binutils: 2.16-r1 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r1 ACCEPT_KEYWORDS="ppc ~ppc" AUTOCLEAN="yes" CBUILD="powerpc-unknown-linux-gnu" CFLAGS="-mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer" CHOST="powerpc-unknown-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig cvs distclean distlocks fixpackages flawfinder nostrip rats sandbox sfperms sign strict" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo http://gentoo.osuosl.org" LANG="ja_JP.utf8" LC_ALL="ja_JP.utf8" LINGUAS="ja ja_JP.utf8 ja_JP en en_US" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="ppc X aalib alsa altivec anthy arts berkdb bitmap-fonts bonobo canna cdparanoia cdr chroot cjk codecs crypt cups curl debug directfb doc dv dvd dvdr emboss erandom esd esound fbcon flac font-server foomatic foomaticdb fortran freewnn gd gdbm ggi gif gimpprint gnome gnomedb gnutls gpm gstreamer gtk gtk2 gtkhtml guile hal imagemagick imlib immqt immqt-bc ithreads jack jacktiff jpeg kde libcaca libwww live lzo mad ming motif mozcalendar mozdevelop mozilla moznocompose moznoirc moznomail mp3 mpeg nas ncurses network nls nomalloccheck nptl ogg oggvorbis opengl pam pdflib perl png portaudio postgres ppds python qt readline samba sane sdk sdl skey sndfile speex spell ssl svg tcltk tcpd tga theora threads tiff truetype truetype-fonts type1-fonts unicode usb userlocales vcd vorbis xanim xine xml xml2 xmms xprint xv xvid zlib linguas_ja linguas_ja_JP.utf8 linguas_ja_JP linguas_en linguas_en_US userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, MAKEOPTS
Was perl 5.8.5 originally built on this box or imported from a stage3? First stab is that the perl that's on the box is confusing this build - which implies that though functional it may not be a "good" install of perl.
Chris, Humor me and remove the emakes (make 'em make's) and try again. I have my suspicions an ancient bug has resurfaced after someone helped clean up the syntax in the perl/libperl ebuilds. thanks, mike
Chris, any followup? I'd like to mark 5.8.6 stable on PPC, but this is holding us up. I haven't been able to reproduce it here.
Chris: has this by any chance had the side effect of messing up thing depending on perl? since *confirming* the bug on my mini i had to recompile a lot of things or else have lot's of missing symbols o_O
hi guys, i was updating my 2005.0 install on my G3 iBook yesterday and i had the same problem with rebuilding perl. i tried rebuilding without ithreads and it built without the error. so this Could be one of those threads thing or it could be something else. but i have been known to be wrong.
ok i have been mucking about with this today i tried using make instead of emake and got the same results. i tried a few other ideas but the one that got the most results was building a clean perl with the options used in the ebuild and it compiled miniperl fine. i did the same with a patched perl (well the one in the portage tmp dir after emerge applies the patches) and it fell over at the same point as listed in the initial report. so to me it seems that the segfault in miniperl is cause by one of the patches. i dont know enough about them to work out which one it would be. if i dont see anything on this in a day or so i shall try and work it out myself. any help appreciated.
ok i got motivated and tried lots of combinations of the patches and the good news is i worked out which one it is. the bad news is that its perl-reorder-INC.patch. this is with 5.8.7 i have not tried with earlier versions but it seems that 5.8.6 uses the same patch. i dont know enough about that patch to work out whats wrong with it.
ok, while working on rendhalver's box, i noticed this while doing an LD_DEBUG=all make : 15953: binding file ./miniperl to /lib/tls/libc.so.6: normal symbol `__ xstat64' [GLIBC_2.2] 15953: symbol=strrchr; lookup in file=./miniperl 15953: symbol=strrchr; lookup in file=/lib/tls/libpthread.so.0 15953: symbol=strrchr; lookup in file=/lib/libnsl.so.1 15953: symbol=strrchr; lookup in file=/lib/libdl.so.2 15953: symbol=strrchr; lookup in file=/lib/tls/libm.so.6 15953: symbol=strrchr; lookup in file=/lib/libcrypt.so.1 15953: symbol=strrchr; lookup in file=/lib/libutil.so.1 15953: symbol=strrchr; lookup in file=/lib/tls/libc.so.6 15953: binding file ./miniperl to /lib/tls/libc.so.6: normal symbol `st rrchr' [GLIBC_2.0] 15361: symbol=strsignal; lookup in file=make 15361: symbol=strsignal; lookup in file=/lib/tls/librt.so.1 15361: symbol=strsignal; lookup in file=/lib/tls/libc.so.6 15361: binding file make to /lib/tls/libc.so.6: normal symbol `strsigna l' [GLIBC_2.0] make: *** [lib/Config.pm] Segmentation fault and looking further (because glibc didn't install a tls on my box), i noticed this: -rwxr-xr-x 1 root root 1336932 Jul 18 08:26 /lib/libc-2.3.4.so -rwxr-xr-x 1 root root 1336840 Jul 18 08:26 /lib/tls/libc-2.3.4.so why are they different? and why is the /lib/tls the one that is being loaded...? I could be off on a tangent here, we all know glibc isn't my specialty, but I think this is worth noting
Rendhalver probably has nptl -nptlonly set in his use flags, which compiles glibc for both the linuxthreads and the NPTL targets. In order for this to work, one version is placed in /lib and the other in /lib/tls. So this is normal.
(In reply to comment #10) > Rendhalver probably has nptl -nptlonly set in his use flags, which compiles > glibc for both the linuxthreads and the NPTL targets. In order for this to > work, one version is placed in /lib and the other in /lib/tls. So this is normal. yeah i do have glibc installed with nptl emerge -vp glibc These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] sys-libs/glibc-2.3.4.20041102-r1 -build -erandom -hardened (-multilib) +nls -nomalloccheck +nptl -nptlonly -pic (-selinux) -userlocales 0 kB mostly because i thought "hey its POSIX and thats a good thing right?" could that be the cause of the problems you think? i am guessing things not using threads wouldn't use the libraries in /lib/tls a friend of mine was thinking that it was crashing because one of the libraries it was calling wasnt really thread safe. so maybe one of the libs it calls when using threads is causing the problems.
It's entirely possible. Michael, is the ithreads version of perl not NPTL safe? Rendhalver: If you emerge perl with LD_ASSUME_KERNEL=2.4.1, does it still break? (This should disable NPTL).
(In reply to comment #12) > It's entirely possible. Michael, is the ithreads version of perl not NPTL safe? > Rendhalver: If you emerge perl with LD_ASSUME_KERNEL=2.4.1, does it still break? > (This should disable NPTL). ok i tried this LD_ASSUME_KERNEL=2.4.1 emerge -v libperl perl but that didnt seem to help. so i exported it first and still no joy is that the right way of passing that var? and have a look here. http://www.dbforums.com/archive/index.php/t-1150798.html anything look familiar? it looks like someone else is having similar problems. and they think that its localtime that isnt thread safe. i also used valgrind (as recomended by a c/c++/c# god friend of mine) i shall attach output of this and a few other tools if anyone knows how to read them.
Chris - were you transitioning from a non-ithreaded perl to an ithread enabled perl in this case? (Rendhalver is, want to confirm a pattern here, thanks :)
i might have a patch for this this afternoon, need to test it a ton on unaffected boxes and perl versions to make sure it doesn't break anyone else, but i think i have it :)
my new reorder patch works on 5.8.7, testing with 5.8.6 now. basically some of the functions we employed, which were originally 'invented' by the debian version of this patch, are now part of the mainstream. so in some cases (for whatever reason, only visible on your ppc box doing ithreads) the reorder patch breaks the building of miniperl. i'm testing this on my box now (already test 5.8.7, testing 5.8.6). if it works here, i'll test it on a ppc under 5.8.6 as well, then post it on here.
(In reply to comment #15) > i might have a patch for this this afternoon, need to test it a ton on > unaffected boxes and perl versions to make sure it doesn't break anyone else, > but i think i have it :) we can test it on my sandbox when i build it tomorrow. and thankt for your help dude.
Created attachment 64394 [details, diff] New version of perl-reorder-INC.patch Please pop this into your dev-lang/perl/files in place of the current perl-reorder-INC.patch (and of course ebuild perl-$VERSION.ebuild digest ;). Please let me know if this works for you - it works on Rendhalver's box which experiences this problem; it works on my boxes which don't; if it works for you I'll add arch testers (ideally, I'd like to get as many possible testers as possible, so if you have suggestions, speak up). In addition to compiling cleanly, make sure afterwards that perl -V ends with an @INC list that starts with site_perl dirs, then vendor_perl dirs, finally the core dirs (whatever your version/threading option was). To be absolutely safe, you should unmerge the libperl you rebuilt and place this patch in the libperl/files dir as well (rebuilding digests) since both invoke the reverse @INC patch. Thanks!
(In reply to comment #18) ok only thing is this from lib/File/Temp/t/security..................uid=250 topuid=10 $<=0 path='/var/tmp/portage/perl-5.8.7/temp/' at ../lib/File/Temp.pm line 686 File::Temp::_is_safe('/var/tmp/portage/perl-5.8.7/temp/', 'SCALAR(0x10306be8)') called at ../lib/File/Temp.pm line 440 File::Temp::_gettemp('/var/tmp/portage/perl-5.8.7/temp/tmpXXXXX', 'open', 1, 'mkdir', 0, 'unlink_on_close', 0, 'suffixlen', 0, ...) called at ../lib/File/Temp.pm line 1273 File::Temp::tempfile('tmpXXXXX', 'DIR', '/var/tmp/portage/perl-5.8.7/temp', 'UNLINK', 1) called at ../lib/File/Temp/t/security.t line 96 eval {...} called at ../lib/File/Temp/t/security.t line 96 main::test_security(0) called at ../lib/File/Temp/t/security.t line 59 uid=250 topuid=10 $<=0 path='/var/tmp/portage/perl-5.8.7/temp/' at ../lib/File/Temp.pm line 686 File::Temp::_is_safe('/var/tmp/portage/perl-5.8.7/temp/', 'SCALAR(0x10306cb4)') called at ../lib/File/Temp.pm line 746 File::Temp::_is_verysafe('/var/tmp/portage/perl-5.8.7/temp/', 'SCALAR(0x10306cb4)') called at ../lib/File/Temp.pm line 446 File::Temp::_gettemp('/var/tmp/portage/perl-5.8.7/temp/tmpXXXXX', 'open', 1, 'mkdir', 0, 'unlink_on_close', 0, 'suffixlen', 0, ...) called at ../lib/File/Temp.pm line 1273 File::Temp::tempfile('tmpXXXXX', 'DIR', '/var/tmp/portage/perl-5.8.7/temp', 'UNLINK', 1) called at ../lib/File/Temp/t/security.t line 96 eval {...} called at ../lib/File/Temp/t/security.t line 96 main::test_security(0) called at ../lib/File/Temp/t/security.t line 68 ok but it said it passed so i dont know if thats bad or not for the record. uname -a Linux ulthwe 2.6.12-gentoo-r6 #1 Mon Jul 18 15:36:50 EST 2005 ppc 750FX PowerBook4,3 GNU/Linux perl -v This is perl, v5.8.7 built for powerpc-linux-thread-multi -snipped the speil- so looks good to me. :)
Looks good to me: Linux pegasos 2.6.9-pegasos-r4 #10 Sun Apr 3 14:02:51 JST 2005 ppc 7447/7457, altivec supported CHRP Pegasos2 GNU/Linux @INC: /etc/perl /usr/lib/perl5/site_perl/5.8.7/powerpc-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.6/powerpc-linux-thread-multi /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.7/powerpc-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.6/powerpc-linux-thread-multi /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.7/powerpc-linux-thread-multi /usr/lib/perl5/5.8.7 /usr/local/lib/site_perl
patch posted in the tree, closing the bug
