Cygwin targetting mingw 32-bit

--------------MlGCT3K2ESpGJECx5cHT7QIy
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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
--------------MlGCT3K2ESpGJECx5cHT7QIy
Content-Type: text/x-chdr; charset=UTF-8; name="floatparam.h"
Content-Disposition: attachment; filename="floatparam.h"
Content-Transfer-Encoding: base64

LyogUm91bmRpbmcgbW9kZXMsIGZvciB1c2UgYmVsb3cgKi8NCiNkZWZpbmUgcm91bmRzX3RvX25l
YXJlc3QgICAgICAgIDAgIC8qIDAuNSB1bHAgKi8NCiNkZWZpbmUgcm91bmRzX3RvX3plcm8gICAg
ICAgICAgIDEgIC8qIDEgdWxwICovDQojZGVmaW5lIHJvdW5kc190b19pbmZpbml0eSAgICAgICAy
ICAvKiAxIHVscCAqLw0KI2RlZmluZSByb3VuZHNfdG9fbWludXNfaW5maW5pdHkgMyAgLyogMSB1
bHAgKi8NCg0KLyogUHJvcGVydGllcyBvZiB0eXBlICdmbG9hdCc6ICovDQovKiBMYXJnZXN0IG4g
Zm9yIHdoaWNoIDErMl4oLW4pIGlzIGV4YWN0bHkgcmVwcmVzZW50ZWQgaXMgMjMuICovDQovKiBM
YXJnZXN0IG4gZm9yIHdoaWNoIDEtMl4oLW4pIGlzIGV4YWN0bHkgcmVwcmVzZW50ZWQgaXMgMjQu
ICovDQojZGVmaW5lIGZsb2F0X21hbnRfYml0cyAyNA0KI2RlZmluZSBmbG9hdF9yb3VuZHMgcm91
bmRzX3RvX25lYXJlc3QNCiNkZWZpbmUgZmxvYXRfcm91bmRzX2NvcnJlY3RseSAxDQoNCi8qIFBy
b3BlcnRpZXMgb2YgdHlwZSAnZG91YmxlJzogKi8NCi8qIExhcmdlc3QgbiBmb3Igd2hpY2ggMSsy
XigtbikgaXMgZXhhY3RseSByZXByZXNlbnRlZCBpcyA1Mi4gKi8NCi8qIExhcmdlc3QgbiBmb3Ig
d2hpY2ggMS0yXigtbikgaXMgZXhhY3RseSByZXByZXNlbnRlZCBpcyA1My4gKi8NCiNkZWZpbmUg
ZG91YmxlX21hbnRfYml0cyA1Mw0KI2RlZmluZSBkb3VibGVfcm91bmRzIHJvdW5kc190b19uZWFy
ZXN0DQojZGVmaW5lIGRvdWJsZV9yb3VuZHNfY29ycmVjdGx5IDANCg0K

--------------MlGCT3K2ESpGJECx5cHT7QIy
Content-Type: text/plain; charset=UTF-8; name="floatparam.h.orig"
Content-Disposition: attachment; filename="floatparam.h.orig"
Content-Transfer-Encoding: base64

LyogUm91bmRpbmcgbW9kZXMsIGZvciB1c2UgYmVsb3cgKi8NCiNkZWZpbmUgcm91bmRzX3RvX25l
YXJlc3QgICAgICAgIDAgIC8qIDAuNSB1bHAgKi8NCiNkZWZpbmUgcm91bmRzX3RvX3plcm8gICAg
ICAgICAgIDEgIC8qIDEgdWxwICovDQojZGVmaW5lIHJvdW5kc190b19pbmZpbml0eSAgICAgICAy
ICAvKiAxIHVscCAqLw0KI2RlZmluZSByb3VuZHNfdG9fbWludXNfaW5maW5pdHkgMyAgLyogMSB1
bHAgKi8NCg0KLyogUHJvcGVydGllcyBvZiB0eXBlICdmbG9hdCc6ICovDQovKiBMYXJnZXN0IG4g
Zm9yIHdoaWNoIDErMl4oLW4pIGlzIGV4YWN0bHkgcmVwcmVzZW50ZWQgaXMgNjMuICovDQovKiBM
YXJnZXN0IG4gZm9yIHdoaWNoIDEtMl4oLW4pIGlzIGV4YWN0bHkgcmVwcmVzZW50ZWQgaXMgNjQu
ICovDQojZGVmaW5lIGZsb2F0X21hbnRfYml0cyA2NA0KI2RlZmluZSBmbG9hdF9yb3VuZHMgcm91
bmRzX3RvX25lYXJlc3QNCiNkZWZpbmUgZmxvYXRfcm91bmRzX2NvcnJlY3RseSAxDQoNCi8qIFBy
b3BlcnRpZXMgb2YgdHlwZSAnZG91YmxlJzogKi8NCi8qIExhcmdlc3QgbiBmb3Igd2hpY2ggMSsy
XigtbikgaXMgZXhhY3RseSByZXByZXNlbnRlZCBpcyA2My4gKi8NCi8qIExhcmdlc3QgbiBmb3Ig
d2hpY2ggMS0yXigtbikgaXMgZXhhY3RseSByZXByZXNlbnRlZCBpcyA2NC4gKi8NCiNkZWZpbmUg
ZG91YmxlX21hbnRfYml0cyA2NA0KI2Vycm9yICJVbmtub3duIHJvdW5kaW5nIG1vZGUgZm9yIHR5
cGUgZG91YmxlISINCg0K

--------------MlGCT3K2ESpGJECx5cHT7QIy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--------------MlGCT3K2ESpGJECx5cHT7QIy
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
clisp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/clisp-devel

--------------MlGCT3K2ESpGJECx5cHT7QIy--