[Openmcl-devel] Failing to build 64 bit ccl/x86
ron at flownet.com
Tue Aug 18 17:53:16 UTC 2009
May I suggest: put the binaries in SVN with a different name than the
ones that get generated during the build, i.e. "dx86cl64-svn, dx86cl64-
svn.image, or something like that. Then as the first step of a clean
build, copy (or move) the -svn files to the correct file names.
On Aug 18, 2009, at 10:23 AM, John McAleely wrote:
> On 18 Aug 2009, at 17:07, Tim Bradshaw wrote:
>> On 18 Aug 2009, at 16:13, Gary Byers wrote:
>>> Someone else who failed to notice the fine print about "svn update"
>>> not updating binaries wound up with both the old kernel and old
>>> 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.)
>> That was me, and I am pretty sure that this diagnosis is right: it
>> all fell to bits at the point it tried loading fasls from the new
>> compiler in the old image / kernel.
> This seems very plausible for my problem too, with one caveat. I do
> not believe I have observed 'conflicted' status on the subversion
> controlled binaries.
> I believe the sequence could be:
> - get a binary from svn
> - rebuild it locally. It now has 'M' status
> - the binary is updated in svn
> - svn up should now result in a conflict for that file. My own
> practice has been to resolve such things as 'theirs-full' at all times
> - now the local binary should not differ from the svn version
> - *here* I build ccl and run in to trouble, for reasons unclear to
> Of course, it is quite likely I've made a mistake driving and
> observing in svn, but I don't have proof of that.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel