[Openmcl-devel] 0.14 darwin build procedure?

[Gary Byers]

On Fri, 4 Jul 2003, Jon Buffington wrote:

> I ran into a problem building 0.14 from source on 3-Jul-03. Any help
> would be appreciated. I run into the following error when I invoke the
> OpenMCL kernel with the bootstrapping image:
>
>
> The only escape is to eXit.
>
> Regards,
> Jon
>
> ---
>
> I downloaded the latest binaries and source (23-Jun) from clozure.com.
> I performed the following steps:
>
> 1) cvs update -d -P

It probably doesn't matter too much at the moment, but it might
be wise to postpone the 'cvs update' until everything's been built
with sources that match the binaries.

>
> 2) rebuilt the darwin kernel (dppccl)
>
> 3) [bobo:local/src/ccl-0.14] jcb% ./dppccl dppccl.image
>  > Error in process listener(1): value #<EQL-SPECIALIZER NIL #x53720BE>
> is not of the expected type (SATISFIES CCL::CLASSP).
>  > While executing: CCL::INVALIDATE-INITARGS-VECTOR-FOR-GF
>  > Type :GO to continue, :POP to abort.
>  > If continued: Skip loading init file.
> Type :? for other options.
> 1 > :go

This got fixed in the post-030623 CVS sources (i.e., just about as soon
as anyone tried to compile a method whose first specializer was an
EQL specializer, IIRC.)  The lisp itself doesn't define any such methods;
it sounds like your init file does.  You might want to rename your init
file (or otherwise prevent it from loading) until you get bootstrapped.

> Welcome to OpenMCL Version (Alpha: Darwin) 0.14-030623!
> ? (ccl::xload-level-0 :force)
> ;Compiling "/usr/local/src/ccl-0.14/level-0/l0-aprims.lisp"...
> ;Compiling "/usr/local/src/ccl-0.14/level-0/l0-array.lisp"...
> ;Compiling "/usr/local/src/ccl-0.14/level-0/l0-bignum.lisp"...
> ...

There should be one (intentional) warning here, to the effect that
"NORMALIZE-AREAS" should be fixed.  That has to do with how (ROOM T)
tries to measure stack usage in other threads and isn't on the
critical path.

> ;Loading #P"/usr/local/src/ccl-0.14/level-0/nfasload.dfsl"...
>   cold-load function:
>   cold-load function:
>   cold-load function:
> NIL
> ? (CCL:COMPILE-CCL t)
> ;Compiling "/usr/local/src/ccl-0.14/compiler/nxenv.lisp"...
> ;Compiling "/usr/local/src/ccl-0.14/compiler/nx.lisp"...
> ; Including "/usr/local/src/ccl-0.14/compiler/nx-basic.lisp"...
> ...

There should be (IIRC) two warnings here.  KILL-LISP-THREAD is undefined
(if a thread won't die cleanly, we ultimately need a way to kill it
uncleanly; at this point, it'd be more interesting to know why it couldn't
die cleanly) and something else having to do with backtrace support that
doesn't even exist in OpenMCL (i.e., unreachable leftover MCL code.)

If you got any other warnings at this step (or during XLOAD-LEVEL-0),
they might shed some light on whatever the real problem is.

> ;Compiling "/usr/local/src/ccl-0.14/lib/describe.lisp"...
> T
> ? (quit)
> [bobo:local/src/ccl-0.14] jcb% ./dppccl ./ppc-boot.image
> ;Loading level-1.dfsl
> ;Loading ./l1-dfsls/l1-cl-package.dfsl
> ;Loading ./l1-dfsls/l1-utils.dfsl
> ;Loading ./l1-dfsls/l1-init.dfsl
> ;Loading ./l1-dfsls/l1-symhash.dfsl
> ;Loading ./l1-dfsls/l1-numbers.dfsl
> ;Loading ./l1-dfsls/l1-aprims.dfsl
> ;Loading ./l1-dfsls/ppc-callback-support.dfsl
> ;Loading ./l1-dfsls/l1-callbacks.dfsl
> ;Loading ./l1-dfsls/l1-sort.dfsl
> ;Loading ./bindarwin/lists.dfsl
> ;Loading ./bindarwin/sequences.dfsl
> ;Loading ./l1-dfsls/l1-dcode.dfsl
> ;Loading ./l1-dfsls/l1-clos-boot.dfsl
>
> ERROR: undefined function call: UNSIGNED-BYTE-P
>
> Continue/Debugger/eXit <enter>?
>

Of course that error makes no sense; it's often the case that an error
that causes a trap (like an attempt to call an undefined function) is
a ways removed from the actual problem.

Choosing (D) at that point (a time or two, confusingly) will get you
to a simple built-in debugger in the kernel; the (B)acktrace and
(L)isp Registers options in that little debugger can sometimes shed
light on how you got to the point of error.

I just tried the whole exercise: I created a new directory, downloaded
the source, darwin binary, and jaguar-interfaces archives, extracted
them, rebuilt everything, did a CVS update, and rebuilt everything
again.  It all worked as I would have expected.

The only obvious difference between what you did and what I did is
that I didn't have an init file that triggered a CLOS bug; it's not
clear why the fact that you had such an init file should have caused
anything to compile differently.

I also built everything from source once before doing a CVS update.
In this case (the post-030623 CVS changes are fairly easy to bootstrap)
that shouldn't matter too much, and I know that people have built
successfully with 030623 binaries and current-as-of-a-few-days-ago
CVS source.  (The whole idea is to try to maintain binaries that are
recent enough/close enough to the CVS head to make that possible.)
Rebuilding in stages (building, doing a CVS update, building again)
might have isolated any problems that might have occurred (though in
this case it's not clear that there would have been any.)

All that I can suggest is that you try renaming your init file and
repeating the process; if you get the same sort of problem, please
let me see the (B) and (L) kernel debugger output.


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