Re: Cygwin targetting mingw 32-bit

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

On 27/09/2022 01:59, Bruno Haible wrote:
> 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?

Oh right. If LN_S is never meant to be applied to directories, then 
that's OK, and it's simply a matter of identifying where all it's used 
for directories.

The top level Makefile in the build directory (from one of my 
configurations) has this for the build-aux target.

build-aux : ../src/build-aux
	-$(RM) build-aux
	-$(LN_S) ../src/build-aux build-aux

A quick check with grep doesn't reveal any other places where LN_S is 
used for directories. Anyway, now that I know the intention, if I come 
across it being used anywhere else for directories, I'll fix that 
specific instance and write in, rather than trying to change the 
definition of LN_S itself.

If build-aux gets fixed in GitLab, I'll immediately pull that down.

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

Super to know, thanks a lot.

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

Oh, that's useful to know. It tells me my experiments needn't go farther 
back than 2018 GitLab. (Though it's now looking like going forward may 
work out, with all these useful notes you've given me.)

One thing to check. You've said elsewhere that 32-bit Cygwin binaries on 
64-bit Cygwin are problematic. Does that also apply to 32-bit mingw 
binaries on 64-bit Cygwin? If not, then I'll keep that configuration on 
my list instead of removing it. (That is, this thread's title stays in 
progress.) My initial goal is not to get unsupported or 
known-problematic configurations working. At first it's just to get all 
the known or thought-to-be-good configurations working for myself, in 
the spirit of walking before I can run.

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

Ha. The tiny application took 2%; writing a licence compliant build 
script and studying licences (18 Lisp libs, Quicklisp, clisp, mingw, 
Cygwin) 40%; building clisp on Windows 58% and counting :-)  It'll be 
fun to get it all perfect eventually. It's going to happen. I'm not in a 
hurry.

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

Very helpful information, thanks. I believe therefore that if I bundle 
everything from sourceforge for clisp 2.49, removing the bz2 file 
(redundant) and mingw-big.zip file (so I don't need to think about the 
other libs in it), and then add the info in your note above about 
versions, that will be a bundling that respects all the various library 
authors' wishes.

Not that that's going to stop me from continuing to try producing my own 
build from the latest source. That still seems worthwhile. And is fun 
regardless.

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

Right, I meant configure flags only in the sense that that particular 
incantation was known to work and is worth getting working before trying 
others.

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

Right, I understand that perfectly. It also means I don't need to 
provide instructions that will work perpetually. Even if they work for 
the moment on some computer, that's good enough. It's just that _I_ 
shouldn't propagate something that I can't build today (and therefore 
most hired programmers won't be able to build today either).

Thanks a lot for all your insight. I'm thrilled to hear from you and get 
this view into clisp.

Vibhu