Today a new release of SBCL showed up and I happily tried to emerge it. Just before it finishes, though, it comes across an error printing the output as shown below in the "Actual Results". Reproducible: Always Steps to Reproduce: 1. emerge sbcl Actual Results: >>> original instance of package unmerged safely. /usr/lib/common-lisp/bin/sbcl.sh loading and dumping clc. [doing purification: roots handlers stack bindings static cleanup done] [undoing binding stack and other enclosing state... done] [saving current Lisp image into /usr/lib/sbcl/sbcl-new.core: writing 18281112 bytes from the read-only space at 0x01000000 writing 6192224 bytes from the static space at 0x05000000 writing 4096 bytes from the dynamic space at 0x09000000 done] /var/tmp/portage/sbcl-0.9.1/work/sbcl-af /var/tmp/portage This is SBCL 0.9.1, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. ; compiling file "/var/tmp/portage/sbcl-0.9.1/work/sbcl-af/static-vector.lisp" (written 22 OCT 2004 08:56:38 AM): ; compiling (IN-PACKAGE "SB-ALIEN") ; compiling (EXPORT (QUOTE #)) ; compiling (DEFSTRUCT (STATIC-VECTOR #) ...) debugger invoked on a SIMPLE-ERROR in thread 17911: Error during processing of --eval option "(|LOAD| \"system\")": Lock on package SB-INT violated when globally declaring the ftype of MAKE-STATIC-VECTOR. See also: The SBCL Manual, Node "Package Locks" Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [IGNORE-ALL ] Ignore all package locks in the context of this operation. 1: [UNLOCK-PACKAGE] Unlock the package. 2: [CONTINUE ] Ignore and continue with next --eval option. 3: [ABORT ] Skip rest of --eval options. 4: Skip to toplevel READ/EVAL/PRINT loop. 5: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ((LAMBDA (SB-IMPL::E)) #<SYMBOL-PACKAGE-LOCKED-ERROR {910E201}>) Expected Results: Install smoothly ;-) First of all: Thanks for the CL ebuilds! It really helped me getting started with common lisp at all. ================================================================= emerge info Portage 2.0.51.19 (default-linux/x86/2005.0, gcc-3.3.5-20050130, glibc-2.3.4.200 40808-r1,glibc-2.3.4.20041102-r1, 2.6.9-gentoo-r13 i686) ================================================================= System uname: 2.6.9-gentoo-r13 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Apr 28 2005, 09:38:27)] dev-lang/python: 2.3.5 sys-apps/sandbox: [Not Present] 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.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.4.3-r4, 1.5.16 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.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/tex mf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/c onfig/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/con trol" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks 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="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm arts artswrappersuid avi bash-completion berkdb bitmap -fonts cdr crypt cups curl doc emacs emboss encode esd fam flac foomaticdb fortr an gd gdbm gif gpm gtk gtk2 guile imagemagick imlib ipv6 java jpeg junit kde lda p libg++ libwww mad mikmod motif mozilla mp3 mpeg mysql ncurses nls odbc ogg ogg vorbis opengl oss pam pdflib perl png python qt quicktime readline ruby samba sd l spell sqlite ssl svg svga tcltk tcpd tetex theora tiff truetype truetype-fonts type1-fonts vorbis xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc " Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS ============================================================================= >emerge -pv sbcl These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-lisp/sbcl-0.9.1 +callbacks +doc +ldb -nosource +threads +unicode 0 kB ============================================================================== > qpkg -I lisp -nc app-xemacs/ilisp dev-lisp/cl-asdf dev-lisp/cl-clx dev-lisp/cl-defsystem3 dev-lisp/cl-gd dev-lisp/cl-mcclim dev-lisp/cl-md5 dev-lisp/cl-ppcre dev-lisp/cl-resolver dev-lisp/cl-sql dev-lisp/cl-uffi dev-lisp/cmucl dev-lisp/common-lisp-controller dev-lisp/hyperspec dev-lisp/sbcl
You're welcome. The problem is "callbacks" in USE. It applies the highly experimental, will-not-be-the-final-sbcl-api, possibly-broken-on-non-x86 patch. This patch used to work with earlier version of SBCL, however it looks like its broken now. As a work around, remove "callbacks" from USE. I am going to fix this bug by removing the callbacks support from the ebuild itself.
I updated the 0.8.21-r1, 0.9.0 and 0.9.1 ebuilds to no longer include support for callbacks. I'm not confident enough to maintain such a "iffie" patch, so I think it is for the best.
(In reply to comment #1) > You're welcome. > > The problem is "callbacks" in USE. It applies the highly experimental, > will-not-be-the-final-sbcl-api, possibly-broken-on-non-x86 patch. This patch used > to work with earlier version of SBCL, however it looks like its broken now. > > As a work around, remove "callbacks" from USE. I am going to fix this bug by > removing the callbacks support from the ebuild itself. Yeah ... I had to drop back to 0.8 something to get Common Music and the callback patch to work. For now, CMUCL works with Common Music, so when SBCL is together with callbacks, I'll revisit it. Meanwhile, do you need any documentation on the specific issues I found with 0.9.x, callbacks, and Common Music?
(In reply to comment #3) > (In reply to comment #1) > > You're welcome. > > > > The problem is "callbacks" in USE. It applies the highly experimental, > > will-not-be-the-final-sbcl-api, possibly-broken-on-non-x86 patch. This patch used > > to work with earlier version of SBCL, however it looks like its broken now. > > > > As a work around, remove "callbacks" from USE. I am going to fix this bug by > > removing the callbacks support from the ebuild itself. > > > Yeah ... I had to drop back to 0.8 something to get Common Music and the > callback patch to work. For now, CMUCL works with Common Music, so when SBCL is > together with callbacks, I'll revisit it. Meanwhile, do you need any > documentation on the specific issues I found with 0.9.x, callbacks, and Common > Music? Forgot to say that I notified Rick Taube (upstream Common Music creator) about this. He's on the SBCL developers' mailing list.
