[Openmcl-devel] Building from CVS

Tue Apr 5 17:51:27 PDT 2005

There have been some pretty drastic ABI changes in the bleeding-edge
tree, and you do need a kernel compiled from CVS + the most recent
image from the /testing directory to compile current bleeding-edge
sources.

When something like this changes, a version number stored in FASL
files also changes; that keeps you from trying to load old code into
a new lisp and vice versa (you'll get a "Wrong FASL version" error,
instead of total confusion about which register points to the current
thread's stack.  It is much, much better to get an error in cases
like this ...)

There's a similar mechanism that tries to prevent an 0.14.x kernel
from loading an 0.13.x image, but it's a little too coarse to be
helpful in cases like this; it'd be good if images carried something
like the FASL version number ("ABI version number") , and if the
kernel had some notion of what "ABI version" it was compatible with.

[The ABI changes - changes in lisp register usage - had to do with the
fact that the Linux port has been hanging on by a thread (pardon the
pun) lately: some Linux distributions' C and thread libraries use the
same register (r2) for thread-local-storage (TLS) that OpenMCL uses
for its own (incompatible) notion of thread-local storage.  Exactly
how severe the problem was tended to be dependent on how aggressively
the distribution used TLS.  The way that things have been juggled
around seems to avoid these issues and should avoid similar conflicts
on ppc64 as well.]

There are some other (ppc64-related) changes in the bleeding-edge tree,
and there will likely be more; some of these can also be hard to
bootstrap, and I'll try to make fairly current bootstrapping images
available in the /testing directory when that happens.

For the last several months (basically since 0.14.2), the
bleeding-edge CVS tree hasn't been bleeding as much as it sometimes
has; it's often just been equivalent to the main tree + bug-fixes,
experimental features (Hemlock), and minor changes.  In order for some
things to move forward, it'll -have- to be more volatile and unstable
than it has been; I -hope- that it'll be total chaos at times, 'cause
that's generally a sign of movement (hopefully forward movement.)

On Tue, 5 Apr 2005, bryan o'connor wrote:

> there are indeed some bootstrapping issues with
> bleeding-edge.
>
> you can grab the a current binary and image from
> the directory below and use them to build.
>
> ftp://clozure.com/pub/testing/
>
>    ...bryan
>
>
> On Apr 5, 2005, at 08.49, David Steuber wrote:
>
> > Hi,
> >
> > Maybe I'm doing something stupid, but I've been using the following
> > shell script to build OpenMCL when I do a cvs up:
> >
> > david at interloper:~/usr/src/ccl-dev/ccl
> > $ cat build-openmcl.sh
> > #!/bin/sh
> >
> > cd lisp-kernel/darwin/
> > make clean
> > make
> > cd -
> >
> > ./dppccl -e "(progn \
> >                (xload-level-0 :force) \
> >                (compile-ccl t) \
> >                (quit))"
> >
> > echo "(save-application \"dppccl.image\")" | ./dppccl ppc-boot.image
> >
> > This has been working fine until I tried it today (first time since
> > just after 0.14.3 was released).  The repository I'm using is:
> >
> > david at interloper:~/usr/src/ccl-dev/ccl
> > $ cat CVS/Repository
> > /usr/local/tmpcvs/ccl-0.14-dev/ccl
> >
> > There are two seperate problems.  When I used the script, the new
> > dppccl went straight into the kernel debugger when it started:
> >
> > Unhandled exception 11 at 0x00004280, context->regs at #xbffff608
> > Read operation to unmapped address 0x6a260006
> >  In foreign code at address 0x00004280
> > ? for help
> > [16404] OpenMCL kernel debugger:
> >
> > I quit out of that because I don't know how to do anything useful
> > with the kernel debugger.  I figured perhaps the new Lisp image was
> > expected to be different, so I restored the old dppccl and tried to
> > just compile the new Lisp image first.  This also failed:
> >
> > ...
> > ;Compiling "/Users/david/usr/src/ccl-dev/ccl/level-0/l0-
> > symbol.lisp"...
> > ;Compiling "/Users/david/usr/src/ccl-dev/ccl/level-0/l0-utils.lisp"...
> > ;Compiling "/Users/david/usr/src/ccl-dev/ccl/level-0/nfasload.lisp"...
> > ;Compiling "/Users/david/usr/src/ccl-dev/ccl/level-0/PPC/ppc-
> > array.lisp"...
> > ;Compiling "/Users/david/usr/src/ccl-dev/ccl/level-0/PPC/ppc-
> > bignum.lisp"...
> > ;Compiling "/Users/david/usr/src/ccl-dev/ccl/level-0/PPC/ppc-
> > clos.lisp"...
> > > Error in process listener(1): Unknown PPC opcode: LDR
> > > While executing: PPC-LAP-INSTRUCTION
> > > Type :GO to continue, :POP to abort.
> > > If continued: Skip evaluation of (progn                (xload-
> > level-0 :force)                (compile-ccl t)                (quit))
> > Type :? for other options.
> > 1 > :pop
> > Welcome to OpenMCL Version (Beta: Darwin) 0.14.3!
> > ? (quit)
> >
> >
> > Maybe I simply checked out a broken file from CVS.  If not, how do
> > I bootstrap to the current bleeding edge?
> >
> > I can just hang back and work with 0.14.3 but I figured that by
> > working with bleeding edge I could also be a tester in the event I
> > somehow exercise a lesser used branch of code.  I can also try
> > going back to CVS and updating from each checkin since 0.14.3 was
> > released.  I think that still leaves a bootstrapping problem
> > though.  How do you normally deal with this issue?
> >
> > Oh, I'm running OS X 10.3.8 on a G4 with the gcc compiler from
> > Xcode 1.5
> >
> > $ gcc --version
> > gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)
> >
> > _______________________________________________
> > Openmcl-devel mailing list
> > Openmcl-devel at clozure.com
> > http://clozure.com/mailman/listinfo/openmcl-devel
> >
> >
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>