[Openmcl-devel] Building from source problem

[Gary Byers]

On Sat, 1 May 2004, Christian Hofer wrote:

> Hello,
>
> due to the current bug w.r.t. the SLIME debugger (failing ABORT, see
> mailing list there), I tried to build OpenMCL from source, downloading
> the newest sources from cvs and the current binary release, following
> the steps of the lisp-build.html within the documentation.
>
> When I tried to build the full image out of the bootstrapping image,
> using:
> ./dppccl ppc-boot.image
> I got the following error:
>
> Unhandled exception 4 at 0x02010004, context->regs at #xbffff558
> ERROR: undefined function call: <
>
> The backtrace is:
> (#xBFFFFA40) #x00004D7C : (subprimitive _ret1valn)
> (#xBFFFFA50) #x02018D7C : #<Function DEREFERENCE-BASE-STRING
> #x06016896> + 32
> (#xBFFFFA60) #x00004D7C : (subprimitive _ret1valn)
> (#xBFFFFA70) #x02018A40 : #<Function %CSTR-POINTER #x060164fe> + 36
> (#xBFFFFA80) #x0202939C : #<Function FOREIGN-SYMBOL-ENTRY #x06020c66> +
> 112
> (#xBFFFFA90) #x020295D8 : #<Function SETUP-LOOKUP-CALLS #x06020f56> + 28
> (#xBFFFFAA0) #x00004D7C : (subprimitive _ret1valn)
> (#xBFFFFAB0) #x0202977C : #<Anonymous Function #x06021056> + 24
> (#xBFFFFAC0) #x0205B72C : #<Anonymous Function #x0603ff66> + 104
> (#xBFFFFAD0) #x0000877C : (subprimitive toplevel_loop)
> (#xBFFFFAE0) #x00008788 : (subprimitive toplevel_loop)
> (#xbffffaf0) #x00008854 : _start_lisp + 180
>
> Is there an easy explanation, s.th. that I made wrong, is this a bug?
> Any help appreciated!

I just did a CVS update, a (COMPILE-CCL T), an (XLOAD-LEVEL-0 :FORCE),
and things compiled and bootstrapped without problems.

The backtrace above shows that the #'< function is undefined, which is
undoubtedly true at this early stage.  Ordinarily, most calls to #'<
are compiled into something simpler (inline code or a simpler, two-
argument comparison), so the fact that the full #'< function hasn't
been defined yet doesn't prevent code which appears to call #'< from
working at this early bootstrapping stage.

Under certain optimization settings, the compiler will refuse to do
this sort of transformation, and it looks like the level-0 sources may
have been compiled under settings that make debugging easier for some
people.  They can't be - they're too sensitive to this sort of thing -
and that suggests that things like XLOAD-LEVEL-0 and COMPILE-CCL should
be made aware of this issue.  (They should either bind the optimization
settings to expected values or warn you if they're different from those
values.)

You can see the current global optimization settings by doing:

? (ccl:declaration-information 'optimize nil)

If this theory is correct, one or more of those flags would have had
a value other than 1 in the environment in which you recompiled things.
It may be the case that SLIME itself is responsible for having made
the OPTIMIZE proclamations/declamations in question; if that's the
case, rebuilding things without SLIME might be the simplest workaround.


>
> Chris
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>