Re: Cygwin 32-bit partial fix: memory map

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

Hi Bruno,

On 27/09/2022 01:12, Bruno Haible wrote:
> Vibhu Mohindra wrote:
>> System: Windows 10, 6 GB RAM, Cygwin (64-bit)
>>
>> I'm now building 32-bit binaries as per INSTALL.windows.
>> ("3. Binaries for the Cygwin environment.")
> 
> Note that in my experience, 32-bit Cygwin binaries on a 64-bit Cygwin
> system don't work right regarding files and filesystem operations,
> depending on circumstances. If you have 64-bit Cygwin, I would thus
> recommend to build 64-bit Cygwin binaries. The INSTALL.windows said
> that libsigsegv is not supported on 64-bit Cygwin; however, since
> libsigsegv version 2.14 it is now supported there too.

Aha. Most useful piece of information. I misunderstood INSTALL.windows 
to think 64-bit Cygwin targetting both 32-bit Cygwin and 32-bit mingw 
was one of the supported configurations. That's the only reason I tried. 
The bottom of INSTALL.windows says to use Cygwin's setup-x86_64.exe, 
which is what misled me. But I realise x86_64 is just the architecture 
name and INSTALL.windows might well have meant I should use that Cygwin 
installer on a 32-bit computer/OS. Your note here probably explains a 
complaint I'm seeing from pathname.d in a different 32-bit target build. 
But to keep things tidy, I won't describe that in this thread.

>> The build produced this error:
>> Warning: reserving address range 0x80000000...0x8000ffff that contains
>> memory mappings. clisp might crash later!
>>
>> The attached change to lispbibl.c got past it. But it was guesswork from
>> scavenging this list, so I don't know if what I've done is definitely
>> right.
> 
> It is perfectly right; you have understood it well! :-)

Hurrah. Having the Makefile print memory layout and marc.out as well 
were brilliant ideas, whoever thought of them.

Super if this goes into GitLab, then I'll pull immediately and always 
reference that Git hash, rather than balancing a precarious stack of 
patches. (Fine if not too, as presumably there'll be a good reason and 
also I now know 64-bit targetting 32-bit is no longer an immediate goal.)

>> If I've understood correctly, one must pick a range not shown in
>> the log, so I did that. (The range I selected was the same as what a
>> neighbouring part of lispbibl.c had specified for win32_native/I80386.)
>>
>> The build then gets at least as far as producing lisp.exe and
>> lispinit.mem that runs in a sane looking way to me.
> 
> Cool! Btw, what's the Cygwin version you use? I use 2.9.0. Maybe the
> memory layout also depends on the Windows version; I don't know.

Oh I see. Right, inside a Cygwin terminal, uname -a prints this:
CYGWIN_NT-10.0-10240 mywin1 3.3.6-341.x86_64 2022-09-05 11:15 UTC x86_64 
Cygwin
Great, I can change to Cygwin 2.9.0 in due course if that turns out to 
matter.

>> Minor aside:
>>
>> I haven't thought about this deeply and may be wrong, but it may be
>> worth improving the Makefile in one way. I think if make fails with a
>> memory map complaint as above and you change no files but simply run
>> make again, it continues and produces a spurious lisp.exe . It would be
>> better for make to fail on its second invocation just as it did on its
>> first. I think the reason for it not failing on second invocation is
>> that marc.out has already been created, so it thinks that step
>> succeeded. One fix is to break marc.out creation into two steps: 1)
>> marc.out.tmp, and if check or whatever succeeded only then to 2) mv
>> marc.out.tmp marc.out
> 
> Hmm. It's not always clear what one wants. Sometimes the "spurious" lisp.exe
> will actually work. Sometimes it does not really work but the developer wants
> to use it under the debugger or strace. So, removing it would not be that
> good. Similarly for marc.out: "keep it simple", I would say.
> Generally what indicates a successful build is the presence of lisp.exe
> plus lispinit.mem.

Got it. So if my invocation of make ever takes more than one attempt to 
get all the way through (i.e. without wastefully cleaning each time), 
then I'll remember to only rely on the binaries if "make check" also 
says they are OK. Super, that'll be my strategy.

>> As a separate matter, the build doesn't get as far as making a base
>> directory. I'll post separately about that as it looks unrelated. So
>> far, I'm happy enough to have got a lisp.exe and lispinit.mem in the
>> build directory itself.
> 
> Yes, lisp.exe + lispinit.mem is the essential thing.

Brilliant. In that case, maybe I won't pursue this build configuration 
any further on a 64-bit machine. If INSTALL.windows also gets updated to 
say 64-bit targetting 32-bit is unsupported or has known file(system) 
problems, then others will also know.

Many thanks Bruno. I might take a bit of a break before resuming my 
overall building exercises. Got notes written carefully.

Vibhu