Math functions like `floor', `ceil', `sqrt', etc. are missing when linking miniperl. Reproducible: Always Steps to Reproduce: 1.emerge '=dev-lang/perl-5.8.8-r5' 2. 3. Actual Results: Fail to emerge. Expected Results: It should be emerged successfully. Portage 2.2.00.11484-prefix (default-prefix/linux/amd64, gcc-4.2.4, unavailable, 2.6.9-42.0.3.ELsmp x86_64) ================================================================= System uname: Linux-2.6.9-42.0.3.ELsmp-x86_64-Dual-Core_AMD_Opteron-tm-_Processor_2212-with-redhat-4.4-Beryllium Timestamp of tree: Tue, 09 Sep 2008 00:01:35 +0000 app-shells/bash: 3.2_p39 dev-lang/python: 2.5.2-r7 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r2 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1-r1 sys-devel/binutils: 2.18.50.0.8 sys-devel/gcc-config: 1.4.0-r04.5 sys-devel/libtool: 1.5.26 ACCEPT_KEYWORDS="amd64-linux ~amd64-linux" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=k8 -O3 -pipe -fomit-frame-pointer" DISTDIR="/home/jin/gentoo_x86_64/usr/portage/distfiles" EPREFIX="/home/jin/gentoo_x86_64" FEATURES="collision-protect distlocks parallel-fetch preserve-libs protect-owned sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US.UTF-8" LDFLAGS="" PKGDIR="/home/jin/gentoo_x86_64/usr/portage/packages" 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="/home/jin/gentoo_x86_64/var/tmp" PORTDIR="/home/jin/gentoo_x86_64/usr/portage" PORTDIR_OVERLAY="/home/jin/gentoo_port_overlay" SYNC="rsync://rsync.prefix.freens.org/gentoo-portage-prefix" USE="X amd64 bzip2 cairo cjk cracklib cscope cvs djvu emacs gd gif gmp gtk iconv imlib jbig jpeg jpeg2k m17n-lib midi mudflap ncurses nls openmp pcre pdf perl plotutils png prefix python readline ssl subversion svg tetex threads tiff truetype unicode xface xinerama xml xpm zlib" 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="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, LINGUAS, MAKEOPTS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Created attachment 164972 [details] dev-lang/perl-5.8.8-r5 build log This is the build log. It also happens when I bootstrap a new prefix environment.
There is something wrong with the following lines in build log. --8<-- Where is your C library? [/lib/libc-2.3.4.so] Extracting names from the following file for later perusal: /lib/libc-2.3.4.so This may take a while....done. <dld.h> NOT found. dlopen() NOT found. Do you wish to use dynamic loading? [n] --8<-- Command `file' says that this is only 32bit: /lib/libc-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), not stripped Those 64bit libraries in my system actually reside in /lib64 and /usr/lib64. /lib64/libc-2.3.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 (SYSV), not stripped Previous version of perl compiles fine in my system, so presumably the developers changed the ebuild file a bit? I looked in the ebuild. Line 302 reads, myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) /$(get_libdir) /usr/$(get_libdir)" I believe as gentoo convention, lib is a symlink to lib64, $(get_libdir) returns lib is reasonable. But my system apparently has a different convention as gentoo does. So what can I do? For now, I manually put lib64 there, so it reads, myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) /lib64 /usr/lib64" And it solved my problem. So now, what do we want to do with this issue? I guess this kind of problem might exist in other ebuilds as well. Do you guys know a general solution?
(In reply to comment #2) > There is something wrong with the following lines in build log. > > --8<-- > Where is your C library? [/lib/libc-2.3.4.so] > Extracting names from the following file for later perusal: > /lib/libc-2.3.4.so > This may take a while....done. > <dld.h> NOT found. > dlopen() NOT found. > Do you wish to use dynamic loading? [n] > --8<-- > > Command `file' says that this is only 32bit: > > /lib/libc-2.3.4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 > (SYSV), not stripped Hence you happen to be on a distro that defaults to a certain word-size, but doesn't align the default library directories (/usr/lib and /lib) to that word-size. In other words: your compiler defaults to 64-bits objects, but your lib directory contains 32-bits objects. Great. > Those 64bit libraries in my system actually reside in /lib64 and /usr/lib64. > > /lib64/libc-2.3.4.so: ELF 64-bit LSB shared object, AMD x86-64, version 1 > (SYSV), not stripped > > > Previous version of perl compiles fine in my system, so presumably the > developers changed the ebuild file a bit? It hasn't changed as far as I'm aware. > I looked in the ebuild. Line 302 reads, > > myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) > /$(get_libdir) /usr/$(get_libdir)" > > I believe as gentoo convention, lib is a symlink to lib64, $(get_libdir) > returns lib is reasonable. But my system apparently has a different convention > as gentoo does. Yes, Gentoo makes sure that /lib eventually points to a place where objects are stored with the same word-size as the compiler produces by default. > So what can I do? For now, I manually put lib64 there, so it > reads, > > myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) > /lib64 /usr/lib64" Maybe we shouldn't add host libpaths at all, or just add all of them (lib lib32 lib64). What happens if you omit the /lib64 and /usr/lib64? Does it find your libc? Do other programs compile correctly? > And it solved my problem. > > So now, what do we want to do with this issue? I guess this kind of problem > might exist in other ebuilds as well. Do you guys know a general solution? Depends entirely on if this problem extends beyond perl or not. If so, we have a huge problem (linker wrapper should catch up then), if not we just need to find a way to fix the perl ebuild for everyone.
(In reply to comment #3) > > Previous version of perl compiles fine in my system, so presumably the > > developers changed the ebuild file a bit? > > It hasn't changed as far as I'm aware. Interesting. I started using prefix portage last year, and things went pretty smooth then. Possibly there is a change in portage broke it. Actually, I haven't upgrade for a while and I just changed to rsync server from the old svn one. So I thought I might broke something with the manual upgrade of portage tree, and I tried a new bootstrap, and that failed, either. > > So what can I do? For now, I manually put lib64 there, so it > > reads, > > > > myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) > > /lib64 /usr/lib64" > > Maybe we shouldn't add host libpaths at all, or just add all of them (lib lib32 > lib64). What happens if you omit the /lib64 and /usr/lib64? Does it find your > libc? Do other programs compile correctly? If I omit the /lib64 and /usr/lib64, perl finds /lib/libc-2.3.4.so and it breaks. So I guess perl doesn't know about /lib64 at all. So far, everything else compiles correctly. I'll file a bug report if I found other broken.
What changed is that Prefix doesn't do lib64 stuff any more. It's always lib, with as effect that get_libdir always returns "lib" in Prefix. I applied the following patch to the perl ebuild, does that work for you? --- perl-5.8.8-r5.ebuild (revision 30390) +++ perl-5.8.8-r5.ebuild (working copy) @@ -299,7 +299,7 @@ [[ ${ELIBC} == "FreeBSD" ]] && myconf "-Dlibc=/usr/$(get_libdir)/libc.a" # We need to use " and not ', as the written config.sh use ' ... - myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) /$(get_libdir) /usr/$(get_libdir)" + myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) /lib /usr/lib /lib64 /usr/lib64 /lib32 /usr/lib32" [[ -n "${LDFLAGS}" ]] && myconf -Dldflags="${LDFLAGS}"
(In reply to comment #5) > What changed is that Prefix doesn't do lib64 stuff any more. It's always lib, > with as effect that get_libdir always returns "lib" in Prefix. > > I applied the following patch to the perl ebuild, does that work for you? > > --- perl-5.8.8-r5.ebuild (revision 30390) > +++ perl-5.8.8-r5.ebuild (working copy) > @@ -299,7 +299,7 @@ > [[ ${ELIBC} == "FreeBSD" ]] && myconf > "-Dlibc=/usr/$(get_libdir)/libc.a" > > # We need to use " and not ', as the written config.sh use ' ... > - myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) > /$(get_libdir) /usr/$(get_libdir)" > + myconf "-Dlibpth=${EPREFIX}/$(get_libdir) ${EPREFIX}/usr/$(get_libdir) > /lib /usr/lib /lib64 /usr/lib64 /lib32 /usr/lib32" > > [[ -n "${LDFLAGS}" ]] && myconf -Dldflags="${LDFLAGS}" > > It works for me. You can consider this bug to be fixed, if it doesn't break other systems.
fixed, thanks
