Mark H Weaver <mhw@netris.org> writes:

> This is generally how things work in Guix.  Similarly, when you compile
> a C program on Guix, the resulting executable depends on the precise
> dynamic linker and shared libraries linked in, and will fail if those
> are garbage collected.  The solution is to either build things as guix
> packages or add an explicit GC root.

I see, thanks for the explanation.  Every time I think I understood
Nix/Guix, it comes out it's even stricter. :-)

> Please write (zero? (system* "sh" "make.sh" "clisp")) instead, to detect
> errors.  It's possible that this will cause the test failures mentioned
> above to cause the build process to fail now.  In that case, those
> particular tests will have to be disabled.

Indeed.  Is the way I disable them OK in the updated patch below?

> To detect errors, how about this:
>
>                (unless (zero? (system* "sh" "install.sh"))
>                  (error "install.sh failed"))
>
>> +               (wrap-program (string-append out "/bin/sbcl")
>> +                 `("SBCL_HOME" = ,(list (string-append out "/lib/sbcl"))))))
>
> It would be preferable to avoid this wrapper.  I looked into this a bit.
> It looks like you can pass --prefix=<out> to 'make.sh', and that will
> become hardcoded into the executable via SBCL_PREFIX and SBCL_HOME (see
> make-config.sh and runtime.c).  It looks like this will also remove the
> need to set INSTALL_ROOT (which will be SBCL_PREFIX by default).
>
> Also, if you don't wrap, then the 'install.sh' call will be at the end
> and you can avoid the 'unless' and 'error' and just put (zero? (system*
> ...)) as the last expression.
>
> The one remaining bit that I'm unsure about is 'sbcl-homedir-pathname'
> in src/code/filesys.lisp.  If it doesn't work nicely, we might consider
> replacing the call to (posix-getenv "SBCL_HOME") with a string literal.
>
> Would you like to try this and see if you run into other problems?

Thanks for looking into it!  Using --prefix= worked, and I didn't need
to patch the getenv call.  One can now still set SBCL_HOME to something
else to override it explicitly, but I guess that would be considered a
feature; the executable runs fine, without a wrapper, when SBCL_HOME is
unset.

Updated patch: