(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) to :do-not-grovel #.(and #-sb-building-contrib t (sb-int:sbcl-homedir-pathname)) 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 x))(asdf:initialize-source-registry "/home/fare/src/sbcl//:")(asdf:initialize-output-translations)(asdf::load-system :sb-grovel)(trace sb-grovel::c-constants-extract) (asdf:load-system :sb-posix))
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.
--#f Multiple instances of a same hacker with different context in his mental cache count as multiple hackers wrt documentation and testing needs.