(rebuild-ccl :full t) fails on windows 7 64-bit

[kodjo]

Building Clozure CL from sources using the standard procedure on Windows 7 64-bit (msys/mingw-w4) fails with:

Error: File exists : "c:/Docume~1/gdr/" While executing: CREATE-DIRECTORY, in process listener(1).

[rme]

I've been using an older cygwin (not msys) and a pretty old mingw on Windows Vista for building the 64-bit Windows kernel.

Note that on Windows, it's necessary to build the lisp kernel separately; that is, one does:

% cd lisp-kernel/win64
% make

and then

% ccl
Welcome to Clozure Common Lisp [...]
? (rebuild-ccl :clean t)

Just recently, I've tried using msys and mingw64 (as downloaded from  http://tdm-gcc.tdragon.net/download) on a Windows 7 system, but Windows complains that the generated wx86cl64.exe file isn't a "valid win32 application". I'm not sure what's up with that...

[kodjo]

I understand the need to build the lisp kernel separately: Windows does not allow overwriting the executable file in use. However, the build failure does not come from building the lisp kernel (which is fine). The failure appears in the next step that rebuild everything else.

I should also note that a build on a Windows 32-bit box completes fines. Only the build on Windows 64-bit fails. I suspect it has to do with the way CREATE-DIRECTORY is currently implemented.

The error message is:

Error: File exists : "c:/Docume~1/gdr/" While executing: CREATE-DIRECTORY, in process listener(1).

[gb]

Replying to kodjo:

I've never tried building the Win64 kernel using MinGW/MSYS tools instead of Cygwin; the WindowsNotes page at http://trac.clozure.com/ccl/wiki/WindowsNotes suggests that it might be possible, then says that it isn't. AFAIK, it works (to use MinGW/MSYS tools) in the case of the Win32 kernel, but I'm surprised that it even compiles and links when MinGW/MSYS tools are used.

Much of the (MinGW) C library is statically linked into the application (we use the MinGW C library even when using the Cygwin toolchain.) Different releases of the Win64 toolchain have offered slightly different C interfaces (current Cygwin-hosted versions don't define the same interfaces that CCL uses in at least some cases.)

I have no idea what causes the reference to the 8.3-style "short name" in the error message, but I'd guess that some C library function that's linked into a kernel built with (some version of) the MinGW-hosted Win64 toolchain doesn't behave the same way as the version that's linked into the wx86cl64.exe that we distribute (which was built with a ~1 year old Cygwin-hosted toolchain.) If you do:

shell> svn revert wx86cl64.exe

does the version that we distribute behave differently ?

Yes, this is a mess

[rme]

Do you still see this problem on the current CCL trunk?

[kodjo]

This is now working fine for me after GB's change. Note that I can build CCL on Win64 with MinGW64 tool chains. The only caveat is that the complete pathname of the directory containing CCL sources should not contain embedded space characters. This is apparantly no longer an issue on Windows 7 since the system provides convenient alias such as /Users/xxx as the home directory of user with login xxx. Therefore the use of DOS-style pathname is no longer an issue (and would not work with CCL anyway.)

Thanks for working on this.