104509 2005-09-01 12:20 0000 [multilib] perl-5.8.7 doesn't build on no-symlinks profile 2005-09-27 02:23:54 0000 1 1 1 Unclassified Gentoo Linux Core system unspecified AMD64 Linux RESOLVED FIXED InCVS P2 normal --- 1 christophe@saout.de amd64@gentoo.org ehmsen@gentoo.org perl@gentoo.org christophe@saout.de 2005-09-01 12:20:20 0000 Emerging perl 5.8.7 fails on a no-symlinks profile. Configure fails to find some libraries in /usr/lib64 since the search paths are incomplete. In my case it fails linking miniperl against libm (undefined reference to floor) and bails out. Adding /lib64 and /usr/lib64 in some places in Configure made it build, but I didn't really test if everything is as it should be, so I'm not providing a patch. Some places are really obvious though, others seem more tricky. Reproducible: Always Steps to Reproduce: 1. 2. 3. jakub@gentoo.org 2005-09-01 15:16:45 0000 Actual errors and emerge --info output missing. christophe@saout.de 2005-09-01 17:34:58 0000 Well, I assumed nobody of you has tried this yet (IWANTTOTRASHMYSYSTEM=1 :) I've also found a fix in the meantime. Ok, anyway: First: "emerge -1 libperl" goes through but the result is messed up: websrv2:/root # file /usr/lib64/libperl.so.1.5.8 /usr/lib64/libperl.so.1.5.8: current ar archive instead of /usr/lib64/libperl.so.1.5.8: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), stripped And "emerge -1 perl" (using that broken libperl) gets as far as this (which looks like the same problem libperl is running into): [...] /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='-O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1'" opmini.o` -fPIC -DPERL_EXTERNAL_GLOB opmini.c CCCMD = x86_64-pc-linux-gnu-gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1 -Wall x86_64-pc-linux-gnu-gcc -L/usr/local/lib -o miniperl \ miniperlmain.o opmini.o libperl.a libperl.a(pp.o): In function `Perl_pp_pow': pp.c:(.text+0x2b57): undefined reference to `pow' libperl.a(pp.o): In function `Perl_pp_modulo': pp.c:(.text+0x3a16): undefined reference to `floor' pp.c:(.text+0x3a61): undefined reference to `fmod' pp.c:(.text+0x3de1): undefined reference to `floor' libperl.a(pp.o): In function `Perl_pp_atan2': pp.c:(.text+0x95b4): undefined reference to `atan2' libperl.a(pp.o): In function `Perl_pp_sin': pp.c:(.text+0x96fe): undefined reference to `sin' pp.c:(.text+0x9794): undefined reference to `sin' libperl.a(pp.o): In function `Perl_pp_cos': pp.c:(.text+0x98de): undefined reference to `cos' pp.c:(.text+0x9974): undefined reference to `cos' libperl.a(pp.o): In function `Perl_pp_exp': pp.c:(.text+0x9d0e): undefined reference to `exp' pp.c:(.text+0x9da4): undefined reference to `exp' libperl.a(pp.o): In function `Perl_pp_log': pp.c:(.text+0x9ef2): undefined reference to `log' libperl.a(pp.o): In function `Perl_pp_sqrt': pp.c:(.text+0xa1f5): undefined reference to `sqrt' libperl.a(pp.o): In function `Perl_pp_int': pp.c:(.text+0xa489): undefined reference to `floor' pp.c:(.text+0xa4e1): undefined reference to `ceil' libperl.a(pp_pack.o): In function `S_pack_rec': pp_pack.c:(.text+0x2ad2): undefined reference to `floor' pp_pack.c:(.text+0x2b12): undefined reference to `floor' collect2: ld returned 1 exit status make: *** [miniperl] Error 1 I'm aware that I'm using a lot of unsupported stuff on my system (and I'm filing this bug to help future development). With the normal 2005.1 profile the system has been stable this way for several weeks and is in heavy use. websrv2:/root # emerge info Portage 2.0.51.22-r2 (default-linux/amd64/2005.1/no-symlinks, gcc-4.0.2-beta20050825-hardenednopie, glibc-2.3.5.20050725-r0, 2.6.12-rc1-cs2 x86_64) ================================================================= System uname: 2.6.12-rc1-cs2 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.0_pre7 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.4.1-r1 sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.91.0.3 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1 -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks multilib-strict sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.inode.at/ ftp://gentoo.inode.at/source/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="de_DE@euro" LINGUAS="de fr en" MAKEOPTS="-j5" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acl acpi alsa amd64 apache2 authdaemond avi berkdb bitmap-fonts bzip2 cairo caps crypt curl devmap droproot eds encode fam foomaticdb fortran gcj gd gdbm gif gpm gs gstreamer gtk2 guile hardened idn imagemagick imap imlib ipv6 java jpeg junit kerberos lcms ldap libg++ libgda libwww lzw lzw-tiff maildir mcal motif mp3 mpeg mysql ncurses nfsv4 nls nptl odbc oggvorbis opengl pam pdf pdflib perl pic png postgres postscript python quicktime quotas readline samba sasl sdl slang snmp source spamassassin spell ssl tcpd tiff truetype truetype-fonts type1-fonts usb userlocales webdav xinerama xml xml2 xpm xv zlib linguas_de linguas_fr linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS christophe@saout.de 2005-09-01 17:38:06 0000 Created an attachment (id=67451) Pass library searchpath as Configure parameter Passing -Dlibpth="/usr/local/$(get_libdir) /$(get_libdir) /usr/$(get_libdir)" as parameter to Configure fixes the problem, so Configure can find the 64 bit shared libraries when lib doesn't point to lib64. The idea is taken from the Redhat SRPM. christophe@saout.de 2005-09-01 17:39:15 0000 Created an attachment (id=67452) same for perl-5.8.7.ebuild christophe@saout.de 2005-09-02 04:44:27 0000 Enough info? jakub@gentoo.org 2005-09-04 04:12:22 0000 Mass re-assign. herbs@gentoo.org 2005-09-05 04:04:23 0000 hmm, can't seem to reproduce this on my no-symlinks system. Could be some kind of libtool problem... Christophe: Thanks for helping test the no-symlinks profile ;-) christophe@saout.de 2005-09-05 05:00:16 0000 Perhaps you can figure it out using the build logs. I've put three logs here: http://www2.saout.de/gentoo/no-symlinks-libperl/ One without no-symlinks as a base for the comparison (which works). One with no-symlinks and unmodified ebuild (broken). And wone with no-symlinks and my "fix" which sets the correct library search paths (which works again). The diffs between the base and the two others are interesting. Here's the diff between the no-symlinks build and my fixed one: http://www2.saout.de/gentoo/no-symlinks-libperl/defaults-vs-fixed.diff As you can see, pretty much identical. The diff vs. the broken one is more interesting: http://www2.saout.de/gentoo/no-symlinks-libperl/defaults-vs-broken.diff As you can see it starts with "dlopen() found." vs. "dlopen() NOT found." and other problems after that and the rest of the build is messed up. Are you by hazard using the nolib32 subprofile so that he finds the the 32 bit libraries under /usr/lib and thinks he found the 64 bit ones which he actually uses then? Since in my case I have lib32 and lib64 so that /usr/lib doesn't contain any binary libraries at all. I think it's easier to catch build problems this way. BTW: I love keeping a chroot environment where I can test bleeding edge stuff. And if I feel kamikaze enough one day I turn it into the actual environment and start testing new stuff. Exciting. :) herbs@gentoo.org 2005-09-05 07:23:31 0000 Whilst I still haven't managed to get it fail quite this spectacularly I've noticed that libperl fails to link to some optional dependencies without specifying libpth like this. herbs@gentoo.org 2005-09-05 07:47:27 0000 Fixed in CVS, thanks Christophe. ehmsen@gentoo.org 2005-09-21 11:40:09 0000 I think I have a problem related to this fix If I try to remerge perl-5.8.7 or upgrade to perl-5.8.7-r1 I get the followin errors: ./config.sh: line 1019: /lib64: is a directory `sh cflags "optimize='-O2 -pipe -march=athlon64'" pad.o` -fPIC pad.c ./config.sh: line 1019: /lib64: is a directory CCCMD = x86_64-pc-linux-gnu-gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -march=athlon64 -Wall ./config.sh: line 1019: /lib64: is a directory `sh cflags "optimize='-O2 -pipe -march=athlon64'" regcomp.o` -fPIC regcomp.c ./config.sh: line 1019: /lib64: is a directory CCCMD = x86_64-pc-linux-gnu-gcc -DPERL_CORE -c -fno-strict-aliasing -pipe -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -fno-stack-protector -O2 -pipe -march=athlon64 -Wall ./config.sh: line 1019: /lib64: is a directory cc1: error: unrecognized command line option "-fno-stack-protector" make: *** [regcomp.o] Error 1 !!! ERROR: dev-lang/perl-5.8.7 failed. !!! Function src_compile, Line 258, Exitcode 2 !!! Unable to make !!! If you need support, post the topmost build error, NOT this status message. I get a lot of ./config.sh: line 1019: /lib64: is a directory I think the added part to the ebuild is the cause, because sometime in the past I could emerge perl-5.8.7 (since it is installed). The only difference from the ebuild from back then and the new one is the following: # diff -u /var/db/pkg/dev-lang/perl-5.8.7/perl-5.8.7.ebuild /usr/portage/dev-lang/perl/perl-5.8.7.ebuild --- /var/db/pkg/dev-lang/perl-5.8.7/perl-5.8.7.ebuild 2005-08-16 23:22:52.000000000 +0200 +++ /usr/portage/dev-lang/perl/perl-5.8.7.ebuild 2005-09-05 17:05:29.000000000 +0200 @@ -1,6 +1,6 @@ # Copyright 1999-2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/dev-lang/perl/perl-5.8.7.ebuild,v 1.9 2005/08/14 15:45:53 mcummings Exp $ +# $Header: /var/cvsroot/gentoo-x86/dev-lang/perl/perl-5.8.7.ebuild,v 1.12 2005/09/05 14:46:39 herbs Exp $ inherit eutils flag-o-matic toolchain-funcs multilib @@ -21,8 +21,7 @@ IUSE="berkdb debug doc gdbm ithreads perlsuid build minimal" PERL_OLDVERSEN="5.8.0 5.8.2 5.8.4 5.8.5 5.8.6" -DEPEND="!elibc_uclibc? ( sys-apps/groff ) - berkdb? ( sys-libs/db ) +DEPEND="berkdb? ( sys-libs/db ) gdbm? ( >=sys-libs/gdbm-1.8.3 ) >=sys-devel/libperl-${PV} !<perl-core/ExtUtils-MakeMaker-6.17 @@ -135,6 +134,8 @@ use elibc_uclibc || replace-flags "-Os" "-O2" # This flag makes compiling crash in interesting ways filter-flags -malign-double + # Fixes bug #97645 + use ppc && filter-flags -mpowerpc-gpopt export LC_ALL="C" local myconf="" @@ -217,6 +218,11 @@ [[ ${ELIBC} == "FreeBSD" ]] && myconf="${myconf} -Dlibc=/usr/lib/libc.a" + if [[ $(get_libdir) != "lib" ]] ; then + myconf="${myconf} -Dlibpth='/usr/local/$(get_libdir) /$(get_libdir) \ + /usr/$(get_libdir)'" + fi + sh Configure -des \ -Darchname="${myarch}" \ -Dcccdlflags='-fPIC' \ The other changes could not cause this problem. Should I reopen this bug or open a new one?!? Btw. I am on amd64 blubb@gentoo.org 2005-09-21 11:58:17 0000 reopening should be enough :) christophe@saout.de 2005-09-21 12:55:55 0000 Huh? Why doesn't you gcc support -fno-stack-protector > cc1: error: unrecognized command line option "-fno-stack-protector"? Gentoo expects gcc to know about this and the others automatically have a stub patch applied. The -fno-stack-protector comes from ${FILESDIR\/perl-5.8.7-regexp-nossp.patch and has nothing to do with the multilib stuff. Anyway, I'm seeing these "./config.sh: line 1019: /lib64: is a directory" too but they don't break the build process in any way. Should be fixed though, it's a bit of an annoyance. Will look into it. ehmsen@gentoo.org 2005-09-22 00:52:24 0000 # gcc-config -l [1] x86_64-pc-linux-gnu-3.4.4 * [2] x86_64-pc-linux-gnu-3.4.4-hardened [3] x86_64-pc-linux-gnu-3.4.4-hardenednopie [4] x86_64-pc-linux-gnu-3.4.4-hardenednopiessp [5] x86_64-pc-linux-gnu-3.4.4-hardenednossp But I don't know anything about -fno-stack-protector and neither does my gcc-manual. Why should that be a legal command-line argument, when it does not appear in the gcc-manual?!? ehmsen@gentoo.org 2005-09-22 01:46:03 0000 The problem is fixed now... I tried re-emerging gcc but _without_ the vanilla use-flag and that fixed the fno-stack-protector thing. It seems gentoo is patching it's gcc-version to allow that flag, but only if the vanilla use-flags isn't set. So you shouldn't relay on all gcc's being able to use it. christophe@saout.de 2005-09-22 03:33:00 0000 It was your decision to compile gcc with the vanilla use flag. Nobody said that the resulting gcc was ready to compile Gentoo pacakges at all. At some point the devs made clear that they expect gcc to know about that flag. Starting with gcc 4.1 it will even know about that flag natively. blubb@gentoo.org 2005-09-22 08:16:34 0000 (In reply to comment #14) > gcc-manual. Why should that be a legal command-line argument, when it does not > appear in the gcc-manual?!? Because simply grepping doesn't always tell you the truth: from man gcc: Many options have long names starting with -f or with -W---for example, -fforce-mem, -fstrength-reduce, -Wformat and so on. Most of these have both positive and negative forms; the negative form of -ffoo would be -fno-foo. This manual documents only one of these two forms, whichever one is not the default. so theoretically it should exist. anyway, this is not an amd64 issue, so please go to bug 97452 :) ehmsen@gentoo.org 2005-09-22 08:37:40 0000 > It was your decision to compile gcc with the vanilla use flag. True > Nobody said that the resulting gcc was ready to compile Gentoo pacakges at all. Nobody said that the resulting gcc wouldn't compile Gentoo packages either. Since gcc is so fundamental to gentoo, it should give some warning when compiled in a way that will result in a non-usable-by-gentoo gcc. I think perl ebuild should at least look for the vanilla use-flag and warn the user that it could cause a problem. > At some point the devs made clear that they expect gcc to know about that flag. Could you please, _please_ tell me where and when they made that "clear". Nobody made that clear to me, and I think the majority of gentoo users doesn't know it either. Not everyone using gentoo follows gcc-devs malinglists :-) > Starting with gcc 4.1 it will even know about that flag natively. What has that got to do with anything. gcc-4* is not even marked unstable in gentoo yet, so it has absolutely no relevanse for anybody except gentoo devs. #17: The vanilla gcc-3.4.4 doesn't recognize -fno-stack-protector... I have tried it! So it's not only in the manual it's missing. But anyway, I've got the problem fixed. jakub@gentoo.org 2005-09-27 02:23:54 0000 Please, don't polute this bug w/ irrelevant comments. Direct your comments on -fno-stack-protector w/ USE=vanilla to Bug 101471. Closing as FIXED. 67451 2005-09-01 17:38 0000 libperl-5.8.7.ebuild: Pass lib64 searchpath to Configure libperl-5.8.7.ebuild.diff text/plain LS0tIGxpYnBlcmwtNS44LjcuZWJ1aWxkLm9yaWcJMjAwNS0wOS0wMiAwMjoxNjozMS4zMDY5NjAy MjYgKzAyMDAKKysrIGxpYnBlcmwtNS44LjcuZWJ1aWxkCTIwMDUtMDktMDIgMDE6NDU6MjkuMzk1 MDU0OTczICswMjAwCkBAIC01NCw3ICs1NCw3IEBACiAKIElVU0U9ImJlcmtkYiBkZWJ1ZyBnZGJt IGl0aHJlYWRzIgogCi1pbmhlcml0IGV1dGlscyBmbGFnLW8tbWF0aWMgdG9vbGNoYWluLWZ1bmNz Citpbmhlcml0IGV1dGlscyBmbGFnLW8tbWF0aWMgdG9vbGNoYWluLWZ1bmNzIG11bHRpbGliCiAK ICMgVGhlIHNsb3Qgb2YgdGhpcyBiaW5hcnkgY29tcGF0IHZlcnNpb24gb2YgbGlicGVybC5zbwog UEVSTFNMT1Q9IjEiCkBAIC0yMjksNiArMjI5LDcgQEAKIAkJLURkX3NlbWN0bF9zZW11biBcCiAJ CS1EY2ZfYnk9J0dlbnRvbycgXAogCQktVWRfY3NoIFwKKwkJLURsaWJwdGg9Ii91c3IvbG9jYWwv JChnZXRfbGliZGlyKSAvJChnZXRfbGliZGlyKSAvdXNyLyQoZ2V0X2xpYmRpcikiIFwKIAkJJHtt eWNvbmZ9IHx8IGRpZQogCiAJZW1ha2UgLWoxIC1mIE1ha2VmaWxlIGRlcGVuZCB8fCBkaWUgIkNv dWxkbid0IG1ha2UgbGlicGVybCQoZ2V0X2xpYm5hbWUpIGRlcGVuZHMiCg== 67452 2005-09-01 17:39 0000 same for perl-5.8.7.ebuild perl-5.8.7.ebuild.diff text/plain LS0tIHBlcmwtNS44LjcuZWJ1aWxkLm9yaWcJMjAwNS0wOS0wMiAwMjoxNTo0MS4wOTIyNjA2MzMg KzAyMDAKKysrIHBlcmwtNS44LjcuZWJ1aWxkCTIwMDUtMDktMDIgMDE6NTI6MTAuNDgxODE5ODEx ICswMjAwCkBAIC0yNDEsNiArMjQxLDcgQEAKIAkJLURpbmNfdmVyc2lvbl9saXN0PSIkaW5jbGlz dCIgXAogCQktRGNmX2J5PSdHZW50b28nIFwKIAkJLVVkX2NzaCBcCisJCS1EbGlicHRoPSIvdXNy L2xvY2FsLyQoZ2V0X2xpYmRpcikgLyQoZ2V0X2xpYmRpcikgL3Vzci8kKGdldF9saWJkaXIpIiBc CiAJCSR7bXljb25mfSB8fCBkaWUgIlVuYWJsZSB0byBjb25maWd1cmUiCiB9CiAK