I've succesfully built SBCL 0.8.20 with the attached ebuild on AMD64, with USE-flags doc, ldb, and unicode. I tried to add callbacks to the USE-flags, but then it wouldn't build anymore.
Created attachment 53463 [details] AMD64-enabled SBCL 0.8.20 ebuild
I compared your ebuild with mine and they're essentially the same approach. Mine had a few other fixes for an upcoming coming commit (warnings about "hardened" features and a fix for a typo in the mips section). I will commit it to portage shortly.
BTW, callbacks support probably won't work on anything but x86 for now. It is Thomas Burdick's alien function patch. It is in the ebuild for the moment because Lambda-GTK and Common Music require it.
I commited a new sbcl-0.8.20 to portage which includes ~amd64 support. I also keyworded dev-lisp/common-lisp-controller and dev-lisp/cl-asdf for ~amd64 which are dependencies. If you want to test it out, try re-emerging sbcl.
I've successfully built sbcl-0.8.20 from portage on amd64. That is, without the callbacks USE-flag. I'm a bit puzzled by the USE-flag issues here BTW. The threads USE-flag silently does nothing on non-x86, and the callbacks USE-flag prints a warning and then fails. How come? And what's the difference that Lambda-GTK and Common Music require the callbacks USE-flag for SBCL? It won't work, so neither will Lambda-GTK and Common Music, right? BTW, the SBCL built printed the style warning "undefined function: INIT-COMMON-LISP-CONTROLLER-V4", but common-lisp-controller using packages seem to work fine.
It is my understanding that threads in SBCL only works for x86. IIRC, callbacks were discussed on the sbcl-devel mailing list recently. Brian Mastenbrook noted problems with the callbacks patch on PPC at least. This is why the ebuild prints a warning message. You mentioned the ebuild prints a warning and then fails. It is not supposed to fail. Does it fail right after the warning is printed, or does it fail right at the end of the emerge, when the image is loaded with callbacks support and then saved back to the filesystem (pkg_postinst)? Common Music uses Lambda-GTK. Lambda-GTK will work on SBCL if Thomas Burdick's callbacks support is present in the image. Callbacks works on x86 w/ Lambda-GTK, at least. It should work on several other platforms (PPC known to be flakey, as described above). Perhaps I should prevent the callbacks USE flag from doing anything on platforms other than x86 -- since that is the only platform I know for sure can run Lambda-GTK.
What happens when I do `USE=callbacks emerge sbcl` is this: First the sources are fetched and unpacked. Then some patches get applied and I get a 'warning': * You have specified the "callbacks" USE flag. Callbacks may only work for x86. * Please refer to README.Gentoo for more information. Then SBCL compiles itself, and finishes with: >>> Completed installing sbcl-0.8.20 into /var/tmp/portage/sbcl-0.8.20/image/ Then the callbacks stuff starts compiling, which quickly drops me in the SBCL debugger: debugger invoked on a SIMPLE-ERROR in thread 25793: Alien-functions are not supported on this architecture. You can type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [CONTINUE] Continue anyway (skipping to toplevel read/eval/print loop). 1: [QUIT ] Quit SBCL (calling #'QUIT, killing the process). ("#'(LAMBDA NIL (ERROR \"Alien-functions are not supported on this architecture.\") ...)") 0] Here I type (sb-ext:quit), dev-lisp/sbcl-0.8.20 is then merged to /, and Portage declares success. However, if you try to start `sbcl` after this, it complains that it can't find its core file.
