Bugzilla Bug 87849

SBCL 0.8.20 fails to merge with the following messages:

SBCL has been installed:
 binary /var/tmp/portage/sbcl-0.8.20/image//usr/bin/sbcl
 core and contribs in /var/tmp/portage/sbcl-0.8.20/image//usr/lib/sbcl/

Documentation:
 man /var/tmp/portage/sbcl-0.8.20/image//usr/share/man/man1/sbcl.1
 info /var/tmp/portage/sbcl-0.8.20/image//usr/share/info/asdf.info (could not add to system catalog)
 info /var/tmp/portage/sbcl-0.8.20/image//usr/share/info/sbcl.info (could not add to system catalog)
 pdf /var/tmp/portage/sbcl-0.8.20/image//usr/share/doc/sbcl-0.8.20/asdf.pdf
 pdf /var/tmp/portage/sbcl-0.8.20/image//usr/share/doc/sbcl-0.8.20/sbcl.pdf
tar: /var/tmp/portage/sbcl-0.8.20/image//usr/lib64/sbcl: Cannot chdir: No such file or directory
tar: Error is not recoverable: exiting now



emerge info:

Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r1, 2.6.11-gentoo-r3 x86_64)
=================================================================
System uname: 2.6.11-gentoo-r3 x86_64 AMD Athlon(tm) 64 Processor 3000+
Gentoo Base System version 1.4.16
Python:              dev-lang/python-2.3.4-r1 [2.3.4 (#2, Mar  1 2005, 21:38:17)]
ccache version 2.3 [enabled]
dev-lang/python:     2.3.4-r1
sys-devel/autoconf:  2.59-r6, 2.13
sys-devel/automake:  1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4
sys-devel/binutils:  2.15.92.0.2-r1
sys-devel/libtool:   1.5.10-r4
virtual/os-headers:  2.6.8.1-r4
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CFLAGS="-march=athlon64 -pipe -fstack-protector -fomit-frame-pointer -O2"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon64 -pipe -fstack-protector -fomit-frame-pointer -O2"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs autoconfig ccache distlocks sandbox"
GENTOO_MIRRORS="ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp.du.se/pub/os/gentoo http://ftp.easynet.nl/mirror/gentoo/"
MAKEOPTS=""
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X aalib acl acpi alsa apache2 arts avi berkdb bitmap-fonts cdr crypt cups curl dvd esd fam flac font-server fortran gdbm ggi gif gtk gtk2 imagemagick imlib ipv6 java jp2 jpeg junit kde lcms leim libcaca libwww lzw lzw-tiff mad mikmod mng motif mozilla mp3 mpeg ncurses nls nptl oggvorbis opengl pam pdflib perl png postgres python qt readline samba sdl speex ssl tcltk tcpd tetex theora tiff timidity truetype truetype-fonts type1-fonts usb userlocales xml2 xmms xpm xrandr xv zlib linguas_en_GB"
Unset:  ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS

That's odd...  What does `ls -l /usr/ | grep lib` say?  I get the following:

# ls -l /usr/ | grep lib
drwxr-xr-x  102 root root 70960 Apr 10 20:24 lib
lrwxrwxrwx    1 root root    25 Mar 15 11:06 lib32 -> ../emul/linux/x86/usr/lib
lrwxrwxrwx    1 root root     3 Mar 13 18:14 lib64 -> lib
drwxr-xr-x    9 root root  1912 Apr  6 20:36 libexec

Hmm, I looked into it further, I think the error's coming from the
impl-save-timestamp-hack function in common-lisp-common-2.eclass - it does

tar cpjf ${D}/usr/share/${impl}/portage-timestamp-compensate -C
${D}/usr/$(get_libdir)/${impl} .

but /var/tmp/portage/sbcl-0.8.20/image/usr only contains bin, lib and share
directories.  So, sbcl's src_install would need to be changed to put things in
/usr/$(get_libdir) instead of /usr/lib.

I don't get this error at all with SBCL on AMD64.  Is my system unusual in that
/usr/lib is a directory and /usr/lib64 a symlink to it?

The error's happening while it's still inside the sandbox, in
/var/tmp/portage/sbcl-0.8.20/image.  Also, it's probably specific to the 2005.0
profile, IIRC that's the first one that's actually refered to lib64 during the
builds.

Dirk, do you have multilib in USE?  I think that I will change the
$(get_libdir), to simply "lib".  Or the other way around.

Matthew, yes I have multilib in USE, because some package (don't remember
which) required GCC to be built with multilib.

I asked the developer who made those changes to the eclasses which caused this 
breakage what "multilibs" means for us.  I'll know what do once i hear back.

I changed the ebuild for sbcl-0.8.21-r1 to use /usr/$(get_libdir) instead of
/usr/lib. This should fix this bug, so I'll mark this resolved with a test
request.

That still didn't do it, but I looked in the ebuild and the install scripts in
more detail - adding

        sed -i "s,/lib,/$(get_libdir),g" ${S}/install.sh

to src_unpack, after extracting the tarball, seems to work, in addition to the
existing changes.  I haven't tested it very extensively, though.

I had the same problem, and solved it as described by David Leverton in comment
#9.  I haven't played around with it a tremendous amount, but I've compiled the
cl-ppcre module and played with it a bit, and it appears to be working.  I was
trying to experiment with mcclim as a large-scale piece of software to verify
things are working, but I couldn't get any examples to run.  However, I think
that is because I don't have any idea what I'm doing yet.

*** Bug 91357 has been marked as a duplicate of this bug. ***

The ebuild for sbcl-0.9.1 just committed to portage applies the fix to
install.sh. Thanks for noting this problem. I'll resolve this with a test
request.

sbcl-0.9.1 works for me now. Thanks.

Works for me also.  Thanks!

thanks for the testing.