[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