Bugzilla Bug 117701

Somewhat related to bug #13970, opening new one because it looks arch-specific.

Emerging dev-lisp/sbcl-0.9.8 and using it with slime works fine.  However, when
launching sbcl in the CL, it fails with:

aja@oberon% sbcl                                                               
                                                                          ~
fatal error encountered in SBCL pid 30570:
can't find core file

--------------------------------------------------------------
sbcl --core /usr/lib/sbcl/sbcl.core works properly.

--------------------------------------------------------------

strace sbcl is productive, with the following near the failure:

stat("/usr/lib6464/sbcl//sbcl.core", 0x7fffff895880) = -1 ENOENT (No such file
or directory)
write(2, "fatal error encountered in SBCL "..., 41fatal error encountered in
SBCL pid 30575) = 41
write(2, ":\n", 2:
)                      = 2
write(2, "can\'t find core file\n", 21can't find core file
) = 21
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?

---------------------------------------------------------------
Note the oddity in the path: 

"/usr/lib6464/sbcl//sbcl.core"  <---------------- lib6464 looks like a typo

----------------------------------------------------------------

aja@oberon% emerge info                                                        
                                                                          ~
Portage 2.1_pre3-r1 (default-linux/amd64/2005.1, gcc-4.0.2, glibc-2.3.6-r1,
2.6.14-gentoo-r5 x86_64)
=================================================================
System uname: 2.6.14-gentoo-r5 x86_64 AMD Athlon(tm) 64 Processor 3500+
Gentoo Base System version 1.12.0_pre12
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.17
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-r1
sys-devel/binutils:  2.16.1-r1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r3
ACCEPT_KEYWORDS="amd64 ~amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=k8 -O2 -pipe -fweb -ftracer"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3.5/env
/usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"
CXXFLAGS="-march=k8 -O2 -pipe -fweb -ftracer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig ccache distlocks multilib-strict sandbox sfperms strict"
GENTOO_MIRRORS="http://distfiles.gentoo.org
http://distro.ibiblio.org/pub/linux/distributions/gentoo"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/etc/portage/overlay"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 X alsa apache2 audiofile avi berkdb bitmap-fonts bzip2 cddb cdr cli
crypt cups dba directfb dts dv dvd dvdr dvdread eds emacs emboss encode esd
exif expat fam fame fbcon ffmpeg firefox foomaticdb fortran gcj gd gdbm gif
glut gmp gpm gstreamer gtk gtk2 idn ieee1394 imagemagick imlib ipv6 java jikes
jpeg junit lcms ldap libwww lirc live lzw lzw-tiff mad mjpeg mng motif mozilla
mp3 mpeg ncurses nls nptl nptlonly nsplugin nvidia ogg oggvorbis opengl pam
pcre pdflib perl png python qt quicktime readline real rtc ruby sdl spell ssl
tcpd tetex theora tiff truetype truetype-fonts type1-fonts udev unicode usb
userlocales v4l v4l2 vorbis xine xml2 xmms xpm xv xvid zlib elibc_glibc
kernel_linux userland_GNU"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS

Do you have any kind of override for get_libdir in effect?

Is SBCL_HOME set in your environment when you execute /usr/bin/sbcl?  If
possible,
please provide the environment context you can sbcl in (eg. "set 
>env-for-matt.txt")

Try putting noclean in your make.conf FEATURES so that
/var/tmp/portage/sbcl-0.9.8
is not wiped out at the end of the emerge (or "ebuild sbcl-0.9.8.ebuild 
unpack") Then examine,

  /var/tmp/portage/sbcl-0.9.8/work/sbcl-0.9.8/src/runtime/runtime.c

A little way down there should be 

  #ifndef SBCL_HOME
  #define SBCL_HOME "/usr/lib/sbcl/"
  #endif

For your error, it should look like SBCL_HOME "/usr/lib6464/sbcl/" ?

If not, then is you SBCL_HOME environment variable set to /usr/lib6464/sbcl/"?

I think the stat in your strace occurs around line 287, in the call to
copied_existing_filename_or_null().

$ ebuild sbcl-0.9.8.ebuild unpack
$ grep /lib /var/tmp/portage/sbcl-0.9.8/work/sbcl-0.9.8/src/runtime/runtime.c
#define SBCL_HOME "/usr/lib6464/sbcl/"

The problem seems to be in the that you are calling sed twice. The first one
does s/lib/lib64 on sbcl-gentoo.patch, the patch then gets applied and you
s/lib/lib64 on the patched file (runtime.c) resulting in lib6464. I would think
the sed on runtime.c can safely be removed which should fix this issue.

The following patch:


aja@oberon% diff -audN /usr/portage/dev-lisp/sbcl/sbcl-0.9.8.ebuild
/etc/portage/overlay/dev-lisp/sbcl/sbcl-0.9.8.ebuild                           
      ~


--- /usr/portage/dev-lisp/sbcl/sbcl-0.9.8.ebuild        2006-01-03
11:31:51.000000000 -0700
+++ /etc/portage/overlay/dev-lisp/sbcl/sbcl-0.9.8.ebuild        2006-01-04
19:59:04.000000000 -0700
@@ -64,7 +64,7 @@
        unpack ${P}-source.tar.bz2
        epatch ${MY_WORK}/sbcl-gentoo.patch || die
        sed -i "s,/lib,/$(get_libdir),g" ${S}/install.sh
-       sed -i "s,\\(.*SBCL_HOME.*\\)/usr/lib,\\1/usr/$(get_libdir),g"
${S}/src/runtime/runtime.c
+#      sed -i "s,\\(.*SBCL_HOME.*\\)/usr/lib,\\1/usr/$(get_libdir),g"
${S}/src/runtime/runtime.c

        cp ${MY_WORK}/customize-target-features.lisp-prefix \
                ${S}/customize-target-features.lisp



Does seem to fix the issue.

The problem comes from the sed as aja has pointed out. it automatically sets
/usr/lib64 already so when sed runs it sets /lib/lib6464 I have removed the
line in ebuild as it does not effect any other arch and commited to the tree
already.