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.
Actual errors and emerge --info output missing.
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
Created attachment 67451 [details, diff] libperl-5.8.7.ebuild: Pass lib64 searchpath to Configure 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.
Created attachment 67452 [details, diff] same for perl-5.8.7.ebuild
Enough info?
Mass re-assign.
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 ;-)
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. :)
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.
Fixed in CVS, thanks Christophe.
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
reopening should be enough :)
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.
# 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?!?
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.
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.
(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 :)
> 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.
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.
