Re: Cygwin targetting mingw 32-bit

[Bruno H. <br...@cl...>]

Vibhu Mohindra wrote:
> 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.

src/makemake.in says that valid values for this variable include
'ln -s', 'ln', and 'cp -p'.

> The reason is that build-aux is a directory, and hard linking 
> directories is not supported.

I don't think it's good for the Makefile to copy an entire build-aux
directory. We should look into how to avoid that. Where is this
happening?

> Does "cp -a" seem a reasonable choice?

Yes, if directories need to be copied as well, then 'ln' and 'cp -p'
won't work and 'cp -a' is better.

> 2. floatparam.h
> 
> The generated floatparam.h has an error message at the bottom that looks 
> like it's causing make to fail.

Oh, this is something I last saw around 2000, when compilers were still
buggy in some places. Often the error goes away if floatparam.c is compiled
with less optimization options.

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

Your floatparam.h is what I get as well on Linux/x86_64 with
$ gcc -m32 -O2 floatparam.c && ./a.out && cat conftest.h
So that is definitely expected (including the
  #define double_rounds_correctly 0
line).

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

Thank you; yes, I haven't tried it on Cygwin since 2018 or so, and
Cygwin as well as Windows evolves over time.

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

Bravo! You have understood what the GPL is about. Even if your neighbour
cannot rebuild things by himself, he could ask a friend or a contractor
to do that for him.

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

Wow, you are giving more thought to the GPL than many other people!

Regarding the ffcall version: Yes, you are right, when distributing
a binary that includes ffcall, the actual version should be specified.
The excuse that we have for omitting this detail is:
  - we have only used released versions, no snapshots, for building
    public binaries,
  - given that these releases maintained compatibility from 1.x to 1.y,
    it does not really matter which release was used. The user will
    get a working binary when rebuilding, regardless of which ffcall
    version they choose.

Regarding the configure flags: If they matter, they should be specified
in the surrounding texts. If they don't matter, they can be omitted.
The idea of the GPL is not to be able to reproduce exactly byte-for-byte the
same binaries — that is a different goal, pursued by reproducible-builds.org —
but merely to allow a user to apply their own modifications and get working
binaries with these modifications.

Regarding the "instructions may have been OK a decade ago on WinXP but don't
work today" argument: The GPL does not mandate source code that will
compile fine 10 years in the future. Even the GCC 3.1, 3.3.6, 4.0.4 source
does not compile out-of-the-box any more on current glibc systems. Thus,
attempting a rebuild on Windows 10 of something that last worked on Windows XP
is quite an adventure, yes. But the license cannot do anything about it.

Bruno