[Openmcl-devel] Failing to build 64 bit ccl/x86

[Gary Byers]

I do a lot of bootstrapping that depends on :clean t/:full t reliably 
deleting fasl files; if it ever failed to do so, I find it difficult
to believe that I wouldn't have noticed.

Someone else who failed to notice the fine print about "svn update"
not updating binaries wound up with both the old kernel and old image
after the recent change; they reported (I think that they just sent
email to me) that the first file that was compiled after the file
containing COMPILE-FILE ("ccl:lib;nfcomp") caused a fasl version
mismatch error when it was loaded.  (COMPILE-FILE had been updated to
use the new fasl version; the loader in the old image still insisted
on the old version.)  There might be other similar scenarios that can
lead to this sort of error, but I find it easier to believe that what
you describe is the result of an inconsistency between binaries and
sources than that it occurs because the :clean and :full options don't
delete fasls.  (The code that does the deletion  just does something
like (DOLIST (F (DIRECTORY "ccl:**;*.FASL")) (DELETE-FILE F)) (where
FASL is the platform-specific fasl extension); if DIRECTORY failed to
find all fasl files or DELETE-FILE quietly failed to delete them, I'd
like to believe that those failures would occur consistently.

(If I'm wrong about that, I'd be very interested in seeing evidence
and anything like a reproducible test case.)

On Tue, 18 Aug 2009, John McAleely wrote:

>> be sufficient to handle those. Then, when rebuilding, make sure to use
>> either :full t or :clean t, which should have the effect of cleaning
>> out existing fasls.
>
> I use  (ccl:rebuild-ccl :full t) and it does not clean out fasls.
>
> At least, every time there is a fasl version change, (ccl:rebuild-
> ccl :full t) fails, because it (appears to) attempt to load a stale
> fasl. I have observed this on both of the recent fasl version changes,
> and I recall it occurring before.
>
> Hence, I believe I need to delete fasls externally to the ccl build
> process.
>
> Perhaps this is a bug, but I've always just shrugged and purged fasl's
> manually.
>
> J
>
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel
>
>