[Openmcl-devel] Error Rebuilding CCL

Chris Van Dusen cavandusen at gmail.com
Thu Jul 24 11:13:35 UTC 2008


And that was indeed the case.  Thanks!

Regarding reverting only those files that are in conflict, short of  
scripting it, I don't know of a way.

Chris.

On Jul 24, 2008, at 4:56 AM, Gary Byers wrote:

> The "couple of days" that Matt mentioned in:
>
> <http://clozure.com/pipermail/openmcl-devel/2008-July/008389.html>
>
> 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