On amd64 (since ~13 days) coreutils does not emerge. Make 139 errors. Dmesg shows perl segfaulting. perl calls help2man. (/usr/bin/help2man) Simply calling help2man already segfaults. (I could not convince gdb&perl to give me any useful backtrace info...) Earlier reference: http://bugs.gentoo.org/show_bug.cgi?id=77440 A simple test here: (http://voidptr.sboost.org/help2man) print "test1.5\n"; textdomain $this_program; { my ($user_locale) = grep defined && length, (map $ENV{$_}, qw(LANGUAGE LC_ALL LC_MESSAGES LANG)), 'C'; sub kark # die with message formatted in the invoking user's locale { setlocale LC_ALL, $user_locale; my $fmt = gettext shift; die +(sprintf $fmt, @_), "\n"; } } print "test2\n"; livecd / # help2man test0 test1 test1.5 Segmentation fault Portage 2.0.51-r15 (hardened/amd64, gcc-3.4.3, glibc-2.3.4.20040808-r1, 2.6.9-gentoo-r1 x86_64) ================================================================= System uname: 2.6.9-gentoo-r1 x86_64 4 Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4 [2.3.4 (#1, Jan 25 2005, 12:14:04)] dev-lang/python: 2.3.4 sys-devel/autoconf: 2.59-r5 sys-devel/automake: 1.8.5-r1 sys-devel/binutils: 2.15.92.0.2-r1 sys-devel/libtool: 1.5.2-r7 virtual/os-headers: 2.4.21-r1 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-O0 -march=k8" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O0 -march=k8" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks nostrip sandbox" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 berkdb crypt hardened ncurses nls pam perl pic pie python readline ssl tcpd zlib" Unset: ASFLAGS, CBUILD, CTARGET, LDFLAGS, PORTDIR_OVERLAY
This is not a hardened issue, the earlier reference contains 2 persons who experienced the same problem, without a hardened setup. I would be happy to run further debugging if I knew some sensible strategies...
As a quick fix this works with the current portage: livecd portage # echo ">dev-lang/perl-5.8.5" >> /etc/portage/package.mask This will emerge: [ebuild R ] dev-lang/perl-5.8.4-r2 +berkdb +debug +doc +gdbm -ithreads -perlsuid (-uclibc) 0 kB which was comitted yesterday. (Problem remains, it is a work around)
Apparently something else in combination with emerging an older (5.8.4) perl version has earlier helped as a workaround. I just did a new stage1 on amd64 and ran into the same problem, my workaround didn't help.... [ebuild R ] dev-lang/perl-5.8.4-r2 +berkdb +debug +doc +gdbm -ithreads -perlsuid (-uclibc) 0 kB # help2man before Segmentation fault Segmentation fault still seems to occur in the same piece of perl code...
Ok, thanks to Alex and the hardened folks. Workaround that actually seems to work: # gcc-config -l [1] x86_64-pc-linux-gnu-3.4.2 * [2] x86_64-pc-linux-gnu-3.4.2-hardenednossp [3] x86_64-pc-linux-gnu-3.4.2-vanilla Select the vanilla gcc specs: # gcc-config 3 # emerge perl Select the hardened gcc specs again: # gcc-config 1 This is an issue with hardened-gcc (specifically pie) and perl... Apparently the perl ebuild should filter pie on perl. My earlier report, that it also occurred when people used non-hardened probably was wrong. I think they used hardened-gcc with the default profile.
When I experienced this problem (see bug 77440) I was not using a hardened gcc. trb@elysium src $ gcc-config -lgcc-g -l [1] x86_64-pc-linux-gnu-3.4.2 [2] x86_64-pc-linux-gnu-3.4.2-hardened [3] x86_64-pc-linux-gnu-3.4.2-hardenednossp [4] x86_64-pc-linux-gnu-3.4.3 * [5] x86_64-pc-linux-gnu-3.4.3-hardened [6] x86_64-pc-linux-gnu-3.4.3-hardenednopie [7] x86_64-pc-linux-gnu-3.4.3-hardenednossp I will probably change to hardened at some point, but I wanted to get the system working well first. But if I now (still on amd64), emerge perl-5.8.5* , the resulting perl is capable of emerging coreutils, so presumably perl manages to execute perl2man okay. This is in contrast to my earlier experience. Perhaps the problem is intermittent, depending on some peculiarities of the particular build or execution environment. Or has someone fixed it in the latest perl-5.8.5* ?
switching from x86_64-pc-linux-gnu-3.4.3 to x86_64-pc-linux-gnu-3.4.3-vanilla solved it for me. I tried it using x86_64-pc-linux-gnu-3.4.3-hardenednopie afterwards to see if it maybe was a PIE issue and it worked, whereas x86_64-pc-linux-gnu-3.4.3-hardenednossp did NOT work (it made help2man segfault again). so there's definitely a problem with PIE.
I recompiled dev-lang/perl-5.8.4-r2 with a PIE+SSP enabled hardened GCC -- this version does NOT make help2man segfault. So it seems something has changed from 5.8.4 to 5.8.5 inside perl, something which doesn't like PIE. any ideas?
I had to edit the help2man perl script to work around this one. Merging with USE=-nls was not enough if I had previously set +nls. The segfasult is caused after help2man spawn perl and help2man the gettext is loaded. /usr/lib/perl5/vendor_perl/5.8.5/x86_64-linux/auto/Locale/gettext/gettext.so --- help2man 2005-02-08 04:23:28.395676704 +0000 +++ help2man.orig 2005-02-08 04:23:36.070509952 +0000 @@ -36,7 +36,7 @@ eval { require Locale::gettext; Locale::gettext->import; - $have_gettext = 0; + $have_gettext = 1; }; unless ($have_gettext)
perl also needs the following patch in order to compile on non hardened amd64 systems. --- x2p/Makefile.SH.orig 2005-02-08 04:51:21.262362312 +0000 +++ x2p/Makefile.SH 2005-02-08 04:51:35.011272160 +0000 @@ -58,7 +58,7 @@ TRNL = '$trnl' -OPTIMIZE = $optimize +OPTIMIZE = -fPIC $optimize .SUFFIXES: .c \$(OBJ_EXT)
My first patch was backwords. It should be - $have_gettext = 1; + $have_gettext = 0;
Ok, this is fixed by upgrading Locale-gettext to 1.03. Confirmed by me on IA64 and by solar on AMD64.
confirmed: =dev-lang/perl-5.8.5-r3 & =dev-perl/Locale-gettext-1.03 works well. please add a dependancy to this new Locale-gettext to all perl ebuilds >=5.8.5.
this has been fixed
