[asdf-devel] [Sbcl-help] cl-fad, sb-grovel and failure to compile constants.lisp-temp

Faré fahree at gmail.com
Wed Aug 18 18:46:59 UTC 2010

(Adding sbcl-devel to a thread started on sbcl-help.)

> Could it be that you're running from a dumped image and that you're
> not exporting SBCL_HOME to a proper value? ASDF does something magic
> with SBCL_HOME for those output files.
> But yeah, I shall submit a patch to SB-GROVEL so that things should
> work even in screwy cases like that.
Easier said than done.
the perform method in sb-grovel/def-to-lisp.lisp has a short-circuit
do-not-grovel, set in sb-posix.asd and sb-bsd-sockets.asd. If I
replace its value from
                 :do-not-grovel #.(progn #-sb-building-contrib t)
                 :do-not-grovel #.(and #-sb-building-contrib t
loading the stuff loses with:
The CC environment variable has not been set in SB-GROVEL. Since this
variable should always be set during the SBCL build process, this
might indicate an SBCL with a broken contrib installation.

Note: I could reproduce the bug this way:
rlwrap xcvb repl
(progn (dolist (x (list :sb-bsd-sockets-system :sb-posix-system
:sb-posix :sb-grovel)) (delete-package x)) (dolist (x (quote
(:sb-posix :sb-grovel))) (asdf::clear-system
:sb-grovel)(trace sb-grovel::c-constants-extract) (asdf:load-system

A more complete solution would involve
(1) having a warning instead of an error there
(2) remembering the build-time value of CC and CFLAGS, etc., and
hoping that they are still valid at runtime, if not overridden by the
user (?)

OR, it may involve
(3) having a way to save a default sb-homedir-pathname in the dumped image, etc.

In any case, it's no trivial endeavor, it requires munging inside the
SBCL build process.

WORKAROUND: be sure to include sb-posix and sb-bsd-sockets in your dumped image.

Multiple instances of a same hacker with different context in his mental
cache count as multiple hackers wrt documentation and testing needs.

More information about the asdf-devel mailing list