Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: Claudius Hamlet <hamletclaud@ya...> - 2008-08-27 07:41:44
When trying to compile sbcl 1.0.19 on a x86-Ubuntu machine (Gutsy) using clisp 2.33.2 as the bootstrap system I run into problems. The binary sbcl version in Ubuntu itself causes our underlying Xen kernel to
My hope was that a self-compiled version might do better. Unfortunately, the build fails with the following stack trace:
** - Continuable Error
EVAL: undefined function HOST-CLOAD-STEM
** - Continuable Error
EVAL: undefined function SB!VM:GENESIS
26.07user 1.52system 0:27.96elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+157794minor)pagefaults 0swaps
//building runtime system and symbol table file
make: Entering directory `/tmp/sbcl-1.0.19/src/runtime'
GNUmakefile:31: genesis/Makefile.features: No such file or directory
make: *** No rule to make target `genesis/Makefile.features'. Stop.
make: Leaving directory `/tmp/sbcl-1.0.19/src/runtime'
Command exited with non-zero status 2
Similar stack traces are reported a number of times on the web, but without any suggestion as to its resolution.I'd be grateful for any hint.
Do You Yahoo!?
Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails.
On Wed, Aug 27, 2008 at 10:41 AM, Claudius Hamlet <hamletclaud@...> wrote:
> When trying to compile sbcl 1.0.19 on a x86-Ubuntu machine (Gutsy) using clisp 2.33.2 as the bootstrap system I run into problems. The binary sbcl version in Ubuntu itself causes our underlying Xen kernel to
Certain (older?) versions of Xen are reputed to be troublesome with
SBCL, but I don't have any further details, unfortunately. The problem
is, however, almost certainly independent of the way SBCL was built.
> My hope was that a self-compiled version might do better. Unfortunately, the build fails with the following stack trace:
> ** - Continuable Error
> EVAL: undefined function HOST-CLOAD-STEM
Clisp is also known to be an unreliable build host (sometimes our
fault, sometimes a Clisp issue). There is likely to be an earlier
error (or a full WARNING) somewhere, though, in this case. Possibly
some of the recentish defstruct changes go against the grain for Clisp
(I vaguely recall an earlier time when a similar error was due to
problematic defstruct code.)