[Openmcl-devel] *initial-process* and *current-process*
Gabriel Dos Reis
gdr at open-axiom.net
Fri Jun 24 17:22:37 PDT 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
> sources
> 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
> directories
> 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.
-- Gaby
More information about the Openmcl-devel
mailing list