dev-perl/XML-Parser may silently fail to build if it is compiled using distcc. The build will complete and will install the modules, and portage will report a successful emerge, but in actual fact, /usr/lib/perl5/vendor_perl/.../auto/XML/Parser/Expat/Expat.so will be invalid. Only when you try to load it will the error become apparent, as DynaLoader.pm will be unable to resolve stk_chk_guard. If installing a new system with distcc, this will probably first become apparent when dev-util/intltool fails to configure, saying that XML::Parser is required, even though you know it is installed. Reproducible: Always Steps to Reproduce: NOTE: REPRODUCIBILITY ON OTHER SYSTEMS NOT KNOWN 1. Enable distcc 2. Emerge dev-perl/XML-Parser 3. Run 'perl -e "require XML::Parser" Actual Results: Portage reports that dev-perl/XML-Parser was successfully emerged, but if there was a distcc problem, Expat.so will contain unresolved symbols and perl will be unable to load it. Expected Results: If Expat.so is not actually loadable, the emerge of dev-perl/XML-Parser should fail. I have been told it is possible to set a flag in an ebuild to disallow distcc for that ebuild. It seems to me that the *safe* fix for this would be to do this and disable distcc for dev-perl/XML-Parser, or add a final-step test to load XML::Parser as in step 3 and, if it fails, warn the user to re-emerge it without distcc.
Alternately, someone could fix the package so that it builds correctly. To do that, the problem will need to be reproduced, or at least analyzed in more detail. Please post the output of emerge --info from both the main build system and all volunteers it used during the build.
emerge --info, build system: Portage 2.1.6.13 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.11-r1, 2.6.32-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.32-gentoo-r1-i686-AMD_Athlon-TM-_XP_2400+-with-gentoo-1.12.13 Timestamp of tree: Thu, 14 Jan 2010 06:45:01 +0000 distcc 3.1 i686-pc-linux-gnu [enabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.9-r2 dev-lang/python: 2.6.4, 3.1.1-r1 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.9.6-r2, 1.10.2, 1.11.1 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -mfpmath=sse -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -mfpmath=sse -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="distcc distlocks fixpackages parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo http://www.gtlib.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo http://gentoo.cites.uiuc.edu/pub/gentoo http://gentoo.osuosl.org ftp://mirrors.rit.edu/gentoo http://mirrors.cs.wmich.edu/gentoo http://mirror.mcs.anl.gov/pub/gentoo" LDFLAGS="-Wl,-O1" MAKEOPTS="-j13" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/perl-experimental" SYNC="rsync://rsync21.us.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl acpi aim alsa apm audacious audiofile bash-completion berkdb bidi branding bzip2 cairo cdda cddb cdparanoia cdr cdrom cli consolekit cracklib crypt cups curl cxx dbus dirac dri dts dvd dvdr emboss encode evo exif ffmpeg firefox flac fltk fortran gadu gcj gd gdbm gif gpg gpm grub gstreamer gtk gtk2-perl hal iconv id3tag imagemagick ipv6 ithreads jabber java jfs jpeg jpeg2k kde ldap libnotify live loop-aes mad matroska md5sum mikmod mmx mmxext mng modules mp3 mp4 mpeg mudflap mysql ncurses netpbm nls nptl nptlonly nsplugin offensive ogg ogg123 opengl openmp pam pcre pdf perl pidgin png ppds pppd python qt3 qt3support qt4 quicktime readline reflection schroedinger sdl sdl-image session silc skins sox speex spell spl sql sse ssh ssl startup-notification stream svg sysfs t1lib tcpd tga theora threads thunar tiff tk tools truetype twolame unicode usb utils v4l v4l2 vlm vorbis win32codecs x264 x86 xanim xface xfs xft xml xorg xorgmodule xpm xscreensaver xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="mga vesa vga" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS emerge --info, build volunteer #1 Portage 2.1.7.16 (default/linux/x86/10.0/desktop, gcc-4.3.4, glibc-2.11-r1, 2.6.32-gentoo-r1-whitestar i686) ================================================================= System uname: Linux-2.6.32-gentoo-r1-whitestar-i686-Mobile_AMD_Athlon-tm-_XP_2500+-with-gentoo-1.12.13 Timestamp of tree: Thu, 14 Jan 2010 06:45:01 +0000 distcc 3.1 i686-pc-linux-gnu [enabled] ccache version 2.4 [disabled] app-shells/bash: 4.0_p35 dev-java/java-config: 2.1.9-r2 dev-lang/python: 2.6.4, 3.1.1-r1 dev-util/ccache: 2.4-r7 dev-util/cmake: 2.6.4-r3 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.13, 2.63-r1 sys-devel/automake: 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11.1 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6b virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -mfpmath=sse -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -march=athlon-xp -mtune=athlon-xp -mfpmath=sse -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests distcc distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms strict unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.chem.wisc.edu/gentoo http://gentoo.osuosl.org http://www.gtlib.gatech.edu/pub/gentoo ftp://mirror.iawnet.sandia.gov/pub/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://cudlug.cudenver.edu/gentoo http://mirrors.cs.wmich.edu/gentoo http://mirror.usu.edu/mirrors/gentoo http://mirror.mcs.anl.gov/pub/gentoo http://gentoo.cites.uiuc.edu/pub/gentoo http://mirror.its.uidaho.edu/pub/gentoo " LDFLAGS="-Wl,-O1" MAKEOPTS="-j13" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/perl-experimental" SYNC="rsync://rsync21.us.gentoo.org/gentoo-portage" USE="3dnow X a52 aac acl acpi aim alsa apm audiofile bash-completion berkdb bidi branding bzip2 cairo cdda cddb cdparanoia cdr cdrom cli consolekit cracklib crypt cups curl cxx dbus dirac divx dri dts dvd dvdr emboss encode evo exif ffmpeg firefox flac fortran gadu gcj gd gdbm gif gpg gpm grub gstreamer gtk gtk2 gtk2-perl hal iconv id3tag imagemagick ipv6 ithreads jabber java jfs jpeg jpeg2k kde ldap libnotify live loop-aes mad matroska md5sum mikmod mmx mng modules mp3 mp4 mpeg mudflap mysql ncurses netpbm nls nptl nptlonly nsplugin offensive ogg ogg123 opengl openmp pam pcre pdf perl pidgin png ppds pppd python qt3 qt3support qt4 quicktime readline reflection schroedinger sdl sdl-image session silc skins sox speex spell spl sql sse ssh ssl startup-notification stream svg sysfs t1lib tcpd tga theora threads thunar tiff tools truetype twolame unicode usb utils v4l v4l2 vlm vorbis vorbis-psy webkit win32codecs x264 x86 xanim xface xfs xft xml xorg xorgmodule xpm xscreensaver xulrunner xv xvid zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="synaptics evdev keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="radeon vesa vga" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS The main compile server helping with this build will be a problem; I can't post an emerge --info from it because it's not a Gentoo machine; it's my main server and runs Solaris 10 x86. It's valuable as a distcc host because it successfully compiles *most* packages and has more compile throughput than all the other readily available potential distcc hosts on my network combined. You're of course 100% correct, the best solution would be to fix the package to compile properly with distcc. However, I don't know how straightforward it's going to be to fix it to compile on distcc with non-Gentoo compile hosts. My experience is that many XS Perl modules fail to build correctly in distcc mode with this set of hosts. (I have not yet tested on a set of all-Gentoo hosts.) The danger in the case of dev-perl/XML-Parser is that the build fails silently, with no indication that it has failed until dependent ebuilds start failing later, possibly much later.
Although distcc supports cross-compilation, mixing in a different machine like that requires some extra care. At a minimum, you need to ensure that it only runs jobs distributed with the fully qualified compiler name of i686-pc-linux-gnu-gcc. Distributing jobs that call cc or gcc is likely to cause problems, since those would run the Solaris native compiler. As a workaround, you may be able to use the Portage bashrc functionality to exclude the Solaris machine from $DISTCC_HOSTS when compiling packages known to cause problems. You can also use distccd's $DISTCC_CMDLIST to ensure that the Solaris machine refuses to serve requests for unqualified compiler names. Although I can appreciate that it causes you some trouble to have the XS builds miscompiled when you stir in this machine, I do not think it is appropriate to completely disable distcc for people who use homogeneous environments just because your heterogeneous environment breaks. Unfortunately, I know of no way to programmatically determine in advance whether a user environment is sufficiently homogeneous to guarantee correct operation.
I think you're missing my point. My point is not that the compile fails on a heterogenous distcc compile. I can easily rebuild failed packages without distcc. The problem is that, unlike every other package that has failed for me in a heterogeneous distcc environment, it fails SILENTLY. It took me a fair bit of detective work when downstream build started failing to identify which package it was that had originally failed. That's the problem here: not that it fails, but that it fails *silently*.
Silent miscompilation causes more trouble than a failed compile, but neither should happen at all. Without knowing specifically why it fails, there is no way to fix the package. Could you attach the build log of a failed run? Also, please apply the techniques described in comment #3 to prevent the Solaris host from serving calls to unqualified names, and attempt to reproduce the problem. If the package is consistently correct with that restriction, then the only remaining problem is to fix the XML-Parser build system to stop using unqualified names. A cursory glance at the generated Makefile does not reveal any use of unqualified cc. However, I am not using the experimental perl overlay.
I can do that, but it'll take me a little while to get to it.
Sorry to be so long getting back to these, I've had my hands full. Build log of a failure follows as requested. Note that portage THINKS the emerge succeeded, although the generated XML/Parser/Expat/Expat.so is actually not valid. It's only when something tries to use the just-generated XS object that things fail. babylon5:root:~:44 # cat /var/tmp/portage/dev-perl/XML-Parser-2.36/temp/build.log >>> cfg-update-1.8.2-r1: Creating checksum index... * CPV: dev-perl/XML-Parser-2.36 * REPO: gentoo * USE: elibc_glibc kernel_linux userland_GNU x86 >>> Unpacking source... >>> Unpacking XML-Parser-2.36.tar.gz to /var/tmp/portage/dev-perl/XML-Parser-2.36/work >>> Source unpacked in /var/tmp/portage/dev-perl/XML-Parser-2.36/work >>> Compiling source in /var/tmp/portage/dev-perl/XML-Parser-2.36/work/XML-Parser-2.36 ... * Using ExtUtils::MakeMaker Checking if your kit is complete... Looks good Writing Makefile for XML::Parser::Expat Writing Makefile for XML::Parser make -j13 OTHERLDFLAGS=-Wl,-O1 make[1]: Entering directory `/var/tmp/portage/dev-perl/XML-Parser-2.36/work/XML-Parser-2.36/Expat' /usr/bin/perl5.10.1 /usr/lib/perl5/5.10.1/ExtUtils/xsubpp -noprototypes -typemap /usr/lib/perl5/5.10.1/ExtUtils/typemap -typemap typemap Expat.xs > Expat.xsc & mv Expat.xsc Expat.c Running Mkbootstrap for XML::Parser::Expat () cp Parser/Encodings/x-sjis-cp932.enc blib/lib/XML/Parser/Encodings/x-sjis-cp932.enc cp Parser/Encodings/iso-8859-7.enc blib/lib/XML/Parser/Encodings/iso-8859-7.enc cp Parser/Style/Tree.pm blib/lib/XML/Parser/Style/Tree.pm cp Parser/Encodings/iso-8859-9.enc blib/lib/XML/Parser/Encodings/iso-8859-9.enc cp Parser/Encodings/x-euc-jp-unicode.enc blib/lib/XML/Parser/Encodings/x-euc-jp-unicode.enc cp Parser/Encodings/README blib/lib/XML/Parser/Encodings/README cp Parser/Encodings/euc-kr.enc blib/lib/XML/Parser/Encodings/euc-kr.enc cp Parser/Encodings/windows-1250.enc blib/lib/XML/Parser/Encodings/windows-1250.enc cp Parser/Encodings/windows-1252.enc blib/lib/XML/Parser/Encodings/windows-1252.enc cp Parser/Encodings/big5.enc blib/lib/XML/Parser/Encodings/big5.enc cp Parser/Encodings/Japanese_Encodings.msg blib/lib/XML/Parser/Encodings/Japanese_Encodings.msg cp Parser/Encodings/iso-8859-3.enc blib/lib/XML/Parser/Encodings/iso-8859-3.enc cp Parser/Style/Subs.pm blib/lib/XML/Parser/Style/Subs.pm chmod 644 Expat.bs cp Parser/Encodings/iso-8859-4.enc blib/lib/XML/Parser/Encodings/iso-8859-4.enc cp Parser/Encodings/iso-8859-8.enc blib/lib/XML/Parser/Encodings/iso-8859-8.enc cp Parser/Encodings/x-euc-jp-jisx0221.enc blib/lib/XML/Parser/Encodings/x-euc-jp-jisx0221.enc cp Expat.bs ../blib/arch/auto/XML/Parser/Expat/Expat.bs cp Parser/Encodings/iso-8859-2.enc blib/lib/XML/Parser/Encodings/iso-8859-2.enc chmod 644 ../blib/arch/auto/XML/Parser/Expat/Expat.bs cp Parser/Encodings/x-sjis-jdk117.enc blib/lib/XML/Parser/Encodings/x-sjis-jdk117.enc cp Parser/Encodings/x-sjis-unicode.enc blib/lib/XML/Parser/Encodings/x-sjis-unicode.enc cp Parser/LWPExternEnt.pl blib/lib/XML/Parser/LWPExternEnt.pl cp Parser/Style/Objects.pm blib/lib/XML/Parser/Style/Objects.pm cp Parser.pm blib/lib/XML/Parser.pm cp Parser/Style/Debug.pm blib/lib/XML/Parser/Style/Debug.pm cp Parser/Encodings/x-sjis-jisx0221.enc blib/lib/XML/Parser/Encodings/x-sjis-jisx0221.enc cp Parser/Style/Stream.pm blib/lib/XML/Parser/Style/Stream.pm cp Parser/Encodings/iso-8859-5.enc blib/lib/XML/Parser/Encodings/iso-8859-5.enc cp Expat.pm ../blib/lib/XML/Parser/Expat.pm i686-pc-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -march=athlon-xp -mtune=athlon-xp -mfpmath=sse -pipe -DVERSION=\"2.36\" -DXS_VERSION=\"2.36\" -fPIC "-I/usr/lib/perl5/5.10.1/i686-linux-thread-multi/CORE" Expat.c rm -f ../blib/arch/auto/XML/Parser/Expat/Expat.so LD_RUN_PATH="/usr/lib" i686-pc-linux-gnu-gcc -shared -O2 -march=athlon-xp -mtune=athlon-xp -mfpmath=sse -pipe -L/usr/local/lib -fstack-protector Expat.o -Wl,-O1 -o ../blib/arch/auto/XML/Parser/Expat/Expat.so \ -L/usr/lib -lexpat \ chmod 755 ../blib/arch/auto/XML/Parser/Expat/Expat.so Manifying ../blib/man3/XML::Parser::Expat.3 make[1]: Leaving directory `/var/tmp/portage/dev-perl/XML-Parser-2.36/work/XML-Parser-2.36/Expat' >>> Source compiled. >>> Test phase [not enabled]: dev-perl/XML-Parser-2.36 >>> Install XML-Parser-2.36 into /var/tmp/portage/dev-perl/XML-Parser-2.36/image/ category dev-perl make -j13 pure_install make[1]: Entering directory `/var/tmp/portage/dev-perl/XML-Parser-2.36/work/XML-Parser-2.36/Expat' make[1]: Leaving directory `/var/tmp/portage/dev-perl/XML-Parser-2.36/work/XML-Parser-2.36/Expat' Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.bs Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Expat.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/LWPExternEnt.pl Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/Japanese_Encodings.msg Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/README Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/big5.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/euc-kr.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-2.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-3.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-4.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-5.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-7.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-8.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/iso-8859-9.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/windows-1250.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/windows-1252.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/x-euc-jp-jisx0221.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/x-euc-jp-unicode.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/x-sjis-cp932.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/x-sjis-jdk117.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/x-sjis-jisx0221.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Encodings/x-sjis-unicode.enc Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Style/Debug.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Style/Objects.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Style/Stream.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Style/Subs.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser/Style/Tree.pm Installing /var/tmp/portage/dev-perl/XML-Parser-2.36/image/usr/share/man/man3/XML::Parser::Expat.3 >>> Completed installing XML-Parser-2.36 into /var/tmp/portage/dev-perl/XML-Parser-2.36/image/ strip: i686-pc-linux-gnu-strip --strip-unneeded -R .comment usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so ecompressdir: bzip2 -9 /usr/share/man * QA Notice: The following files contain writable and executable sections * Files with such sections will not work properly (or at all!) on some * architectures/operating systems. A bug should be filed at * http://bugs.gentoo.org/ to make sure the issue is fixed. * For more information, see http://hardened.gentoo.org/gnu-stack.xml * Please include the following list of files in your report: * Note: Bugs should be filed for the respective maintainers * of the package in question and not hardened@g.o. * RWX --- --- usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so A quick after-compile test: babylon5:root:~:45 # perl -e 'use XML::Parser;' Can't load '/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so' for module XML::Parser::Expat: /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so: undefined symbol: __stack_chk_guard at /usr/lib/perl5/5.10.1/i686-linux-thread-multi/DynaLoader.pm line 200. at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser.pm line 14 Compilation failed in require at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser.pm line 14. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser.pm line 18. Compilation failed in require at -e line 1. BEGIN failed--compilation aborted at -e line 1. That "undefined symbol: __stack_chk_guard" is a common factor in all of these related failures, suggesting very strongly that the problem involves -fstack-protector support in some way. That's more my problem than yours, though. I'm trying to see whether I can resolve the problem with different compile options on the i686-pc-solaris-2.10 to i686-pc-linux-gnu cross-compiler on the Solaris x86 compute server (though, really, i686-pc-solaris-2.10 to i686-pc-linux-gnu cross-compilation is almost a NOP). It's worth noting that dev-perl/XML-LibXML also falls foul of this problem in a related way: it builds, installs an invalid XML/LibXML.so, then tries to remove and re-add XML::LibXML::SAX::Parser in its configuration, which fails. Portage does in this case detect and warn about the failure: >>> Installing (1 of 1) dev-perl/XML-LibXML-1.70 * Update Parser: remove XML::LibXML::SAX::Parser * Update Parser: remove XML::LibXML::SAX * Update Parser: add XML::LibXML::SAX::Parser Can't load '/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/LibXML/LibXML.so' for module XML::LibXML: /usr/lib/perl5/vendor_perl/5.10.1/i686- inux-thread-multi/auto/XML/LibXML/LibXML.so: undefined symbol: __stack_chk_guard at /usr/lib/perl5/5.10.1/i686-linux-thread-multi/DynaLoader.pm line 200. at /usr/lib/perl5/5.10.1/i686-linux-thread-multi/DynaLoader.pm line 153 BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/LibXML.pm line 153. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/LibXML/SAX/Parser.pm line 15. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/LibXML/SAX/Parser.pm line 15. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.10.1/XML/SAX.pm line 147. * Update Parser: add XML::LibXML::SAX::Parser failed * Update Parser: add XML::LibXML::SAX Can't load '/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/LibXML/LibXML.so' for module XML::LibXML: /usr/lib/perl5/vendor_perl/5.10.1/i686- inux-thread-multi/auto/XML/LibXML/LibXML.so: undefined symbol: __stack_chk_guard at /usr/lib/perl5/5.10.1/i686-linux-thread-multi/DynaLoader.pm line 200. at /usr/lib/perl5/5.10.1/i686-linux-thread-multi/DynaLoader.pm line 153 BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/LibXML.pm line 153. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/LibXML/SAX.pm line 17. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/LibXML/SAX.pm line 17. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.10.1/XML/SAX.pm line 147. * Update Parser: add XML::LibXML::SAX failed * Messages for package dev-perl/XML-LibXML-1.70: * Update Parser: add XML::LibXML::SAX::Parser failed * Update Parser: add XML::LibXML::SAX failed >>> Auto-cleaning packages... >>> No outdated packages were found on your system. * GNU info directory index is up-to-date. The dev-perl/XML-Parser build, though, shows no indication whatsoever at the time that it has failed. The one-liner "perl -e 'use XML::Parser;'", though, does provide a very simple and reliable test for the failure mode. I suspect (but have not verified for certain) that any Perl XS module has the potential to fail in this way in a heterogeneous distcc environment, but so far dev-perl/XML_Parser is the only ebuild I have found that fails completely silently.
Considering this slipped through the cracks and I went months without responding, I do not think you have much to apologize for over a mere one month delay. ;) (In reply to comment #7) > babylon5:root:~:44 # cat /var/tmp/portage/dev-perl/XML-Parser-2.36/temp/build.log Attaching build logs is preferable to pasting them inline. Attaching preserves formatting, which can make a big difference in readability due to the way Bugzilla applies line wrapping. > i686-pc-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing > -pipe -fstack-protector Where did this -fstack-protector come from? Your emerge --info does not show it. > * QA Notice: The following files contain writable and executable sections > * RWX --- --- > usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so This is strange. I do not have an RWX Expat.so using the main tree XML-Parser, nor do I see any bug reports touched this year about an RWX stack in XML-Parser. > undefined symbol: __stack_chk_guard at This is also weird. On my hardened builds, the only stack protection related symbol is __stack_chk_fail. A Google search suggests __stack_chk_guard is a variable meant to be used to seed the canary, but that seems to be unused in the latest version of gcc. Instead, the seed is fetched inline from an anonymous memory location designated by %fs/%gs (depending on architecture). > That "undefined symbol: __stack_chk_guard" is a common factor in all of these > related failures, suggesting very strongly that the problem involves > -fstack-protector support in some way. That's more my problem than yours, > though. How was the cross gcc built? The output of "i686-pc-linux-gnu-gcc -v" from all three machines could be helpful. Pasting that inline is fine.
> (In reply to comment #7) > > babylon5:root:~:44 # cat > /var/tmp/portage/dev-perl/XML-Parser-2.36/temp/build.log > > Attaching build logs is preferable to pasting them inline. Sorry ... my error. > > i686-pc-linux-gnu-gcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing > > -pipe -fstack-protector > > Where did this -fstack-protector come from? Your emerge --info does not show > it. That's a good question. I didn't do anything when emerging gcc to get it; I do have stack-protect turned on in my kernels, but that's the only place. > > That "undefined symbol: __stack_chk_guard" is a common factor in all of these > > related failures, suggesting very strongly that the problem involves > > -fstack-protector support in some way. That's more my problem than yours, > > though. > > How was the cross gcc built? The output of "i686-pc-linux-gnu-gcc -v" from all > three machines could be helpful. Pasting that inline is fine. Well, I can give you my native compiler, and the native compiler on the Solaris box. Those are: # i686-pc-linux-gnu-gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.3-r2/work/gcc-4.4.3/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.3 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.3/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.4.3/python --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.3-r2 p1.2' Thread model: posix gcc version 4.4.3 (Gentoo 4.4.3-r2 p1.2) # i686-pc-solaris2.10-gcc -v Using built-in specs. Target: i686-pc-solaris2.10 Configured with: ../configure --build=i686-pc-solaris2.10 --host=i686-pc-solaris2.10 --target=i686-pc-solaris2.10 --prefix=/usr/local --with-arch=nocona --enable-multilib --enable-bootstrap --with-gnu-as --with-gnu-ld --enable-languages=c,c++ Thread model: posix gcc version 4.4.3 (GCC) However, I can't give you the compiler data from the other Gentoo machine, since it's an eMachines laptop that I got (used) in late fall, which turns out to have such horribly marginal thermal design that it's not stable in summer. And I can't give you the i686-pc-linux-gnu-gcc from the Solaris box, because in the interim I've upgraded all my machines to gcc-4.4.3 and I have so far met with utter failure in building a new cross-compiler (though almost everything will actually build and work using a link to i686-pc-solaris2.10-gcc). About the best I can do is show you the latest version of my cross-compile build script on the Solaris machine: #!/bin/bash CONFIG_SHELL=/bin/bash CC=gcc CFLAGS="-march=nocona -mfpmath=sse -pipe" CXXFLAGS="-march=nocona -mfpmath=sse -pipe" LDFLAGS="-Xlinker -L/usr/local/lib -R/usr/local/lib" ../configure --host=i686-pc-solaris2.10 --build=i686-pc-solaris2.10 --target=i686-pc-linux-gnu \ --prefix=/usr/local --disable-multilib --disable-bootstrap --with-gnu-as --with-gnu-ld \ build_alias=i686-pc-solaris2.10 host_alias=i686-pc-solaris2.10 target_alias=i686-pc-linux-gnu \ --with-sysroot=/opt/linux --with-arch=nocona --enable-languages=c,c++ Before we get too diverted on figuring out why my rather atypical environment is failing at times to build working XS modules, though, let me repeat that the original problem I was trying to report was not that the build was not yielding a working module in my heterogeneous distcc build environment; the problem was that the failure was *silent*, and was not being detected by the build system until other builds dependent upon the failed package started failing. I've actually found the problem to be widespread: *many* perl XS modules will successfully emerge a [module].so that does not actually work. Unfortunately, despite some experiment, I've yet to figure out a practical way to test before completing the emerge whether the newly built XS module actually loads, because although I can force the use of the new module as in the following example: # perl -I/var/tmp/portage/dev-perl/XML-Parser-2.36-r1/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser -MExpat -e 'print "Hello world\n";' ...this still loads the *installed* XML/Parser/Expat/Expat.so instead of the newly built one. I have a somewhat *impractical* one, which is to temporarily swap the installed and just-built XS .so before performing the above test, which yields the example below: # perl -I/var/tmp/portage/dev-perl/XML-Parser-2.36-r1/image/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/XML/Parser -MExpat -e 'print "Hello world\n";' Can't load '/usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so' for module XML::Parser::Expat: /usr/lib/perl5/vendor_perl/5.10.1/i686-linux-thread-multi/auto/XML/Parser/Expat/Expat.so: undefined symbol: __stack_chk_guard at /usr/lib/perl5/5.10.1/i686-linux-thread-multi/DynaLoader.pm line 200. at -e line 0 Compilation failed in require. BEGIN failed--compilation aborted. ...then swap them back before completing the emerge. Of course, this is unsatisfactory for two obvious reasons: (1) it can only be done as root, and (2) it still results in *temporarily* installing an XS .so module that may not actually work. (Of course, I suppose the latter is better than permanently installing a non-working .so and failing to detect the fact. But there has to be a better way to test for a broken XS module.)
(In reply to comment #9) > That's a good question. I didn't do anything when emerging gcc to get it; I do > have stack-protect turned on in my kernels, but that's the only place. If gcc were configured to have it by default (as the hardened gcc series does), it would not show up in the command line. If you did not add it, then it is probably coming from the Perl module build system. It looks like the build system places your $CFLAGS after the ones it sets, so it would be interesting to try explicitly listing -fno-stack-protector in your $CFLAGS to see if that suppresses the stack guard behavior throughout the package. Obviously, we should not leave stack protection turned off. My guess is that something about the Solaris-hosted cross gcc differs in some key detail about stack protection. Perhaps it was drawn from slightly different sources than the Gentoo one, or configured differently from how Gentoo configures its native compiler. Getting the source from gcc.gnu.org is not necessarily sufficient to exactly match up to a distribution's compiler. > (though almost everything will actually build and work using a link to i686-pc-solaris2.10-gcc). That is an unusual way to work around it. Personally, I would not trust objects built that way. ;) > let me repeat that the > original problem I was trying to report was not that the build was not yielding > a working module in my heterogeneous distcc build environment; the problem was > that the failure was *silent*, and was not being detected by the build system > until other builds dependent upon the failed package started failing. Yes, the original problem is fairly basic. Linux shared objects are normally allowed to have unresolved symbols at link time, with the expectation that everything will be straightened out at load time. When it is not handled, the library fails to load, as happened to you. You can disallow this behavior with -Wl,--no-allow-shlib-undefined, but be aware that there are some packages which are designed to be broken with that option (e.g. plugins where the symbol comes from some other library that the host program ensures is loaded) and there may be other Gentoo packages that, while they could be made to work with that option, presently do not. Therefore, you will get noisy failures for cases like this, but at the price of breaking packages that would otherwise have worked. Such packages can be reported and patched so that they do work, assuming they are not in the category of "broken by design". Given the stack protection related issue, I think the conditions for building a broken module are that: - stack protection is enabled - distcc sends a C file to the Solaris machine such that the sent file has at least one function that triggers the SSP code to add a stack guard The randomness is probably because not all files in the package have a buffer that triggers the stack guard, so it is unpredictable whether the Solaris compiler will get a file that it miscompiles. You could probably get a reliable test case by changing $DISTCC_HOSTS so that _all_ work is sent to the Solaris machine, with no files compiled locally or on the other Gentoo machine. > Unfortunately, despite some experiment, I've yet to figure out a practical way > to test before completing the emerge whether the newly built XS module actually > loads Does setting LD_LIBRARY_PATH for the call to perl adjust the search order in a useful way? Since all known breakage seems related to this bad stack guard variable, you could also try a bashrc hook that uses nm to check the object file for reference to the offending variable (untested): find "${D}" -name '*.so' -print0 | xargs -0 nm --print-file-name --dynamic --undefined-only | grep __stack_chk_guard > "${T}"/stack-chk-guard.log if [ -s "${T}"/stack-chk-guard.log ]; then die "Modules referenced __stack_chk_guard. See ${T}/stack-chk-guard.log" fi
(In reply to comment #10) > (In reply to comment #9) > > (though almost everything will actually build and work using a link to i686-pc-solaris2.10-gcc). > > That is an unusual way to work around it. Personally, I would not trust > objects built that way. ;) Hence why I'm still trying to get a proper cross-compiler built ;) > Given the stack protection related issue, I think the conditions for building a > broken module are that: > - stack protection is enabled > - distcc sends a C file to the Solaris machine such that the sent file has at > least one function that triggers the SSP code to add a stack guard Sounds plausible to me. > > Unfortunately, despite some experiment, I've yet to figure out a practical way > > to test before completing the emerge whether the newly built XS module actually > > loads > > Does setting LD_LIBRARY_PATH for the call to perl adjust the search order in a > useful way? I don't know, I haven't tried that, and I should have thought of it. I'll try to remember to give it a shot tomorrow. > Since all known breakage seems related to this bad stack guard variable, you > could also try a bashrc hook that uses nm to check the object file for > reference to the offending variable (untested): > find "${D}" -name '*.so' -print0 | xargs -0 nm --print-file-name --dynamic > --undefined-only | grep __stack_chk_guard > "${T}"/stack-chk-guard.log > if [ -s "${T}"/stack-chk-guard.log ]; then > die "Modules referenced __stack_chk_guard. See > ${T}/stack-chk-guard.log" > fi That approach hadn't occurred to me.
(In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > (though almost everything will actually build and work using a link to i686-pc-solaris2.10-gcc). > > > > That is an unusual way to work around it. Personally, I would not trust > > objects built that way. ;) > > Hence why I'm still trying to get a proper cross-compiler built ;) Oh, I should probably add that I'm doing all the preprocessing locally and only distributing the actual compilation, which is probably why that works at all. The same preprocessed code on the same architecture should yield interoperable object code, and clearly usually does. But that, along with building all Perl modules with distcc disabled, are still just stopgap workarounds until I can figure out why my cross-compiler won't build.
Don't saw this behaviour in last stable. Reopen if bug still actual.
