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

[Gary Byers]

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

> On Fri, Jun 24, 2011 at 4:05 AM, Gary Byers <gb at clozure.com> wrote:
>> 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.
>
> I followed that advice on the Wiki page and did the renaming.  If that advice
> is believed to be incorrect, then it should be removed (but I don't think
> they are incorrect, but then I'm not familiar with CCL enough to make
> a definitive comment).
>

No, it's not strictly incorrect.  I personally find it more confusing 
than the alternative that  I recommended, but it should avoid the issue.

I'd also completely missed the fact that you said that you'd done this,
and just leapt to flaming Windows for making this an issue.  Sorry for
the confusion.

>> ?It's often easier to just do:
>>
>> ? (rebuild-ccl :clean t) ? ? ? ?; delete all fasl files, recompile all lisp
>
> Doing this led to level-0 being compiled; but then failed
> with
>
>   > Error: Errors (:ERROR 2) reloading boot image:

Reloading the lisp image at that point involves running wx86cl64.exe.
You've renamed that file, didn't rebuild it (because of the toolchain/
symbol-underscores issue), and the crytic error message is saying
that the attempt to run wx86cl64.exe to build a new image failed
because that file doesn't exist.

(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.)



>
>> code
>>
>> in CCL, quitting all running CCL instances, and doing
>>
>> $ cd ccl/lisp-kernel/win64
>> $ make
>>
>> to build the kernel without confusing Windows.
>
> this is where the build failure happens as I reported.
> It does not change whether I attempt the build failure
> in several steps as I outlined or just in one step
> through the renaming.

Yes.  That failure has to do with the fact that the toolchain that you're
using follows C symbol naming different conventions than the kernel sources
expect.  There were other reasons for insisting on the use of an older version
of the toolchain (having to do with changes in DIRECTORY support function),
but the current trunk lisp sources don't use those problematic functions
anymore.

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.

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.)


>
>> 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.)
> [...]
>
>> 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 ...
>
> 1. I am using CCL as a Lisp system to deliver an application to end-users.
>    Consideration of why people use Windows in the first place does not
>    really matter -- telling my users that they are dumb in using Windows
>    is not going to make my application used by more people.
>

I don't know.  I've tried telling Windows users that they're smart,
but that doesn't seem to work either: I get the impression that they
doubt my sincerity.  There doesn't seem to be any way to win here ..



> 2. the problem as I reported, and your analysis above, seem to indicate that
>    the build issue has more to do with the mangling of C function names than
>    with the filesystem issue you mention above.

The win64 heap image in svn in the trunk is fairly old (r14415, from early
November of last year.)  The change to DIRECTORY was made in r14581 in mid-January.
In the older image, DIRECTORY calls into the lisp kernel and the version of the
library functions it finds there depends on the version of the toolchain used
to build the kernel.

One step in putting this issue to rest is to simply check in a more recent
wx86cl64.image; I'll try to do that soon.

>
> Thanks anyway.  Now, I think I have an idea about why I can't build
> CCL on Windows 7 64-bit using msys/mingw64.


>
> -- Gaby
>
>