Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=67451) [details]
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.

Created an attachment (id=67452) [details]
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.