[Openmcl-devel] *initial-process* and *current-process*
Gabriel Dos Reis
gdr at open-axiom.net
Sat Jun 25 00:22:37 UTC 2011
On Fri, Jun 24, 2011 at 10:53 AM, Gary Byers <gb at clozure.com> wrote:
> (This is an example of why I think the "rename the kernel" strategy
> can be more confusing.)
> If at this point you:
> - postpone dealing with the kernel compilation issue
> - rename the kernel back to "wx86cl64.exe"
> - run that kernel and do either:
> a) ? (rebuild-ccl) ; that'll be quicker if you still have all the fasls
> ; from earlier
> b) ? (rebuild-ccl :clean t) ; that'll take a minute or so, but will delete
> ; all of the fasls and rebuild them
> then I would expect that to produce a new heap image that matches the
> you have (or at the very least get much further into that process.)
Yes, that works.
> The change to ccl/lisp-kernel/m4macros.m4 that I mentioned earlier does
> resolve the symbol-naming issue. I'd like to commit that change to svn
> soon, but there's a little bit of a chicken-and-egg issue there: you should
> be able to build a kernel with a newer Win64 toolchain, but the heap image
> that you use with that has to be new enough to avoid using the problematic
> functions. We definitely want to make this change soon.
The M4 trick also works.
> If you want to compile the kernel after making that simple change to
> the m4macros.m4 file, then my best guess is that it'd work for you. (The
> part that I'm unsure of has to do with differences between Cygwin and MinGW;
> if those differences exist, they're likely to be minor - e.g., which
> to look in for shared libraries that the kernel is linked against.)
My understanding is that cygwin has adopted mingw64 changes, at least for
recent enough versions of GCC.
More information about the Openmcl-devel