Cygwin targetting mingw 32-bit

[Vibhu M. <vi...@ho...>]

System: Windows 10 64-bit, 6 GB RAM
Processor: Intel Xeon X5647, x64-based processor
Cygwin (64-bit) targetting mingw 32-bit
clisp revision: f1aa42219433f019c05e707220538b3634bc233c
I've used the instructions in INSTALL.windows.


----
1. LN_S

The Makefile has a variable LN_S that is chosen to be some platform 
dependent value.

LN_S = ln
is not a suitable choice, at least for Cygwin targetting mingw 32-bit.
The reason is that build-aux is a directory, and hard linking 
directories is not supported.

LN_S = ln -s
might be a valid choice, but I don't know if symlinks would cause 
problems in the resulting native binary, or further in the build.

LN_S = cp -p
as recommended in some make/config file I can't remember offhand is also 
not a valid choice as that won't work for directories such as build-aux.

LN_S = cp -a
is probably a valid choice. I don't think the build ever does:
$(LN_S) x y
and then changes y expecting changes to be reflected in x.

Any tips on how I can reliably override LN_S in all primary and 
subsidiary make and config files will be most appreciated. My manual 
editing may not be addressing all required files and may be getting 
overwritten by some of the build. Does "cp -a" seem a reasonable choice?


----
2. floatparam.h

The generated floatparam.h has an error message at the bottom that looks 
like it's causing make to fail. So I re-ran the build afresh, but this 
time immediately after the configure step, I replaced floatparam.h with 
a copy from another build configuration I had lying around (Cygwin 
targetting Cygwin 32-bit). Doing that got make further along.
Please see attached files: floatparam.h.orig (which is the actual one 
generated for the mingw32 target build) and floatparam.h (the copy that 
got me further, taken without good reason from a Cygwin build that 
targetted Cygwin 32-bit).

I'd love to know what I need to do to have configure create a proper 
floatparam.h directly. (And also what a proper floatparam.h is to begin 
with, instead of my guessed copy.)

Note: I do always remember to start a fresh Cygwin terminal and to set 
PATH afresh and ulimit -s 16384 afresh. It's not the case that one build 
interferes with another.


----
Background of what I'm up to:
(Please feel free to ignore all this)

I'm building the various supported configurations listed in 
INSTALL.windows. Some errors appear in many configurations. So I'll be 
careful to try and list/resolve them in a sensible order and always be 
clear which configuration I'm talking about. I presume nobody's tried 
most of them in a long time and that they don't work for anybody any 
more. We know from the other recent thread that one configuration does 
work now, which is cool.

Of the various errors, the two above are good starts, being dependent on 
none of my other hacks trying to build things. They were produced by 
following INSTALL.windows to the letter.


Here's why I've embarked on this exercise in the first place. I've 
written a command-line GPL'ed Lisp application for a non-technical 
neighbour who only uses Windows. I don't know Windows well, but have now 
got myself access to a Windows system. Besides pure clisp, the 
application needs :ffi and thus ffcall. The most I can expect of my 
neighbour is to double-click on an executable. So I'd like to be able to 
give him a (GPL'ed) application rather than have him download clisp from 
here, ffcall from there, then merge it all together. That would be 
beyond him. So I plan to produce a single zip file with the application 
binary and also all GPL-mandated sources, licences and build instructions.

A mingw binary is valuable as it reduces how much I need to source, 
build and describe. I'll only need to source ffcall and clisp, then 
verify and write up how to rebuild them. A Cygwin binary on the other 
hand also requires me to source, build and document the production of 
cygwin1.dll (and cyggcc_s-1.dll). I'll do that work if I must, but nice 
to avoid. So a mingw target is valuable.

Note: I don't believe I'm allowed to distribute the official clisp mingw 
binaries from sourceforge because its *features* have :ffi, so they have 
ffcall in them. But they don't say which version. Or how to rebuild the 
binaries (e.g. configure flags that were used). Even without ffcall, 
I've been unable to produce mingw binaries from that old version of 
clisp. So it seems against at least the spirit of the GPL for me to 
distribute such binaries knowing that their instructions may have been 
OK a decade ago on WinXP but don't work today and so their recipient 
won't really be able to use them to rebuild the binary. In other words, 
I shouldn't propagate a binary that I know the recipient can't modify 
from source and rebuild because their instructions are obsolete.

Easily distributable clisps will make distributing GPL'ed clisp 
applications to non-technical people easy. That's what I'm after.


-- 
Vibhu