[Openmcl-devel] Error Rebuilding CCL

Gary Byers gb at clozure.com
Thu Jul 24 09:56:17 UTC 2008

The "couple of days" that Matt mentioned in:


might have been a little optimistic (e.g., the trunk is still
pretty volatile as he merges several months' worth of IA-32 changes
into it.)

As of Wednesday afternoon, the trunk does build on Darwin/x8664
(with recent images; the most recent Darwin/x8664 image was checked
in as r10191 and identifies itself as "1.2-r10180M-trunk".)

The fact that SVN handles binary files reasonably well is a good thing,
but one common case that comes up often involves binary files to which
you've made local modifications (the lisp kernel and heap image usually
fall into this category.)  "svn update" downloads newer files and stores
them in a parallel directory hierarchy (.svn directories), then compares
them to the corresponding files in your working copy.  If your local
copy wasn't modified since it was last checked out, it's overwritten
with the new copy.  If a text file was modified, svn will try to 
automatically reconcile the changes in your version with the new version;
if it can, you get a working merged version and if it can't, it flags
the file as "conflicting" and adds some annotations that indicate which
parts of the attempted merge came from which version.

If a binary file's in conflict ... well, a binary merge would be an
interesting research project.  Since it can't really do any sort
of binary merge, svn leaves the locally modified copy alone and
notes that a conflict exists.  (Even if you've never changed the
source, a lisp heap image that you make yourself may not be bit-for-bit
identical to the same version from the server: some internal pathnames
may be different, there may be timestamps somewhere, ...)

You can see those conflicts by doing:

shell> cd ccl           # your working copy
shell> svn status

I'd guess that "svn status" sould show something like

C    dx86cl64.image

and maybe

C    dx86cl64

indicating that "svn update" didn't really know how to merge the
locally-modifed copy.

'svn update' has already downloaded a copy of everything in the
repository (and stored it in a .svn directory), so you can do:

shell> svn revert dx86cl64.image

which basically says "discard my local modifications to the specified
file and replace the working copy with the last version obtained from
the server."

If there's a convenient way to say "do 'svn revert' on all files
that 'svn status' reports as being in conflict", I don't know what
it is.

Anyway, the symptom is "trying to use an old image to compile new
sources", and if you just did an "svn update" and still have
an old image, this is a plausible explanation.  Binary files
don't change that often, but when they do it's necessary to be
aware of the fact that svn can't do much but (conservatively)
not update the working copy.

On Wed, 23 Jul 2008, Chris Van Dusen wrote:

> Hi,
> I'm trying to rebuild bleeding edge CCL from the command line
> (Leopard, X86_64), and am getting the following:
> ? (ccl:rebuild-ccl :full t)
> ;Building lisp-kernel ...
> ;Kernel built successfully.
> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/nxenv.lisp"...
> ;Loading #P"/Users/chrisvandusen/bin/ccl/bin/nxenv.dx64fsl"...
> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/nx.lisp"...
> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx-basic.lisp"...
> ; Including "/Users/chrisvandusen/bin/ccl/compiler/lambda-list.lisp"...
> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx0.lisp"...
> ; Including "/Users/chrisvandusen/bin/ccl/compiler/nx1.lisp"...
> ;Compiler warnings for "/Users/chrisvandusen/bin/ccl/compiler/
> nx0.lisp" :
> ;   In MAKE-AFUNC: Undefined function %MAKE-AFUNC
> ;Loading #P"/Users/chrisvandusen/bin/ccl/l1-fasls/nx.dx64fsl"...
> ;Compiling "/Users/chrisvandusen/bin/ccl/compiler/optimizers.lisp"...
> > Error: Undefined function %MAKE-AFUNC called with arguments () .
> > While executing: MAKE-AFUNC, in process listener(1).
> > Type :GO to continue, :POP to abort, :R for a list of available
> restarts.
> > If continued: Retry applying %MAKE-AFUNC to NIL.
> > Type :? for other options.
> 1 >
> The warning seems a foreshadowing of the error to come, but that's
> just me guessing.  If there's any more info that might be helpful, let
> me know.
> Thanks,
> Chris.
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel

More information about the Openmcl-devel mailing list