Re: Cygwin 32-bit partial fix: memory map

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.

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

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

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

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

Bruno





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