[Openmcl-devel] *initial-process* and *current-process*

[Gary Byers]

As noted on

<http://trac.clozure.com/ccl/wiki/WindowsNotes>

you basically can't do (rebuild-ccl :full t) on Windows.  The :FULL T
option will try to rebuild the kernel, and that would ordinarily involve
overwriting the execuctable file that you're running.  Windows' filesystem
doesn't support that.

Someone edited that Wiki page to suggest running a renamed kernel and
using (REBUILD-CCL :FULL T) to work around this.  It's often easier
to just do:

? (rebuild-ccl :clean t)        ; delete all fasl files, recompile all lisp code

in CCL, quitting all running CCL instances, and doing

$ cd ccl/lisp-kernel/win64
$ make

to build the kernel without confusing Windows.

All well and good, but the log indicates that the kernel compilation wasn't
going to be successful.  We "officially" only support building the lisp
kernel using the Cygwin tools, though in practice the MinGW toolchain should
work as well.  I believe that it does for Win32, but there are other Win64-
related issues that're noted on that Wiki page.  (The Win64 GCC toolchain
is relatively new and has changed a bit over its lifetime; some of those
changes affect how the CCL kernel is compiled and some of them cause
misbehaviors in lisp code, and we actually recommend using an older version
of the Cygwin toolchain to build the Win64 kernel.)

Those differences are:

1) older versions of the toolchain followed the convention that C symbol
    names are preceded by underscore characters at the assembler/linker
    level (so "main" is actually "_main"); newer versions don't prepend
    underscores (so "main" is just "main").  Disagreement about this (between
    the compiler you were using and the CCL assembly-language sources) caused
    all of the "undefined symbol" errors in the log file.

    The assembly-language sources can use either convention; they're set up
    to believe that it's an attribute of the target OS and not of the particular
    C compiler that you're using.  A more robust solution would probably involve
    testing the compiler's behavior and passing a command-line argument to 'm4'.
    A quick and dirty workaround would involve changing the definition in
    ccl/lisp-kernel/m4macros.m4.  Around line 75:

ifdef(`WINDOWS',`define(`SYSstabs',`COFFstabs')
                define(`CNamesNeedUnderscores',`')
                define(`LocalLabelPrefix',`L')
 	       define(`StartTextLabel',`Ltext0')
 	       define(`EndTextLabel',`Letext')')

    If we conditionalize the definition of CNamesNeedUnderscores so that it only
    happens on 32-bit Windows, that'd happpen to be correct (unless/until the Win64
    toolchain changes again, or someone tries to use an older version, or ...)

ifdef(`WINDOWS',`define(`SYSstabs',`COFFstabs')
   ifdef(`WIN_32',`define(`CNamesNeedUnderscores',`')')
                define(`LocalLabelPrefix',`L')
 	       define(`StartTextLabel',`Ltext0')
 	       define(`EndTextLabel',`Letext')')

    then the kernel will build with a newer toolchain, at least under Cygwin.

2) The toolchain provides a static C library; a little bit of code from that
    library gets linked into the CCL kernel.  Some functions in that library
    have changed their interfaces over time; this includes the POSIX functions
    opendir()/readdir()/and friends, which historically were used in CCL in
    the implementation of DIRECTORY.  (The net effect is that compiling the
    lisp kernel with a new Win64 toolchain broke directory.)

    I changed the implementation of DIRECTORY on Windows to not use these
    functions and I don't believe that there's anything else in CCL that
    uses these (potential moving-target) C library functions.  I don't
    remember whether this change was made before or after 1.6 was released.

I made the change to m4macros.m4 as indicated above, installed the latest
version of the Cygwin-hosted win64 toolchain, and used it to build a kernel.
DIRECTORY seemed to work in a lisp using that kernel.  That's all encouraging,
and it may mean that we'll soon be able to remove the restrictions that're
mentioned on the WindowsNotes Wiki page. Until that happens, those restrictions
still exist (whether you read that page or not.)

The restriction on not being able to overwrite a running executable is imposed
by Windows and there's no reason to believe that it'll be removed soon; if people
want a more functional file system, they wouldn't be using Windows ...





On Fri, 24 Jun 2011, Gabriel Dos Reis wrote:

> On Thu, Jun 23, 2011 at 10:03 PM, Gary Byers <gb at clozure.com> wrote:
>
>> Whatever is keeping the 64-bit CCL from building for you on some Windows 7
>> boxes won't likely get fixed if no one who could fix it knows about it.
>
> Attached to this mail, you'll find a log.
> Set up:
>  1. I am using msys shell from www.mingw.org
>       and GCC-4.5.2 from mingw64.
>  2. the box is a Windows 7 64-bit.
>  3. Checked out the SVN windows directory to D:/clozure.svn
>  4. Copied wx86cl64.exe to ccl.exe
>                  wx86cl64.image to ccl.image
>  5. Ran
>         echo '(ccl:rebuild-ccl :full t)' | ./ccl 2>&1 | tee b.log
>     Result is attached.
>
> -- Gaby
>