Question about clisp version naming

Ken Brown kbrown@cornell.edu
Tue Mar 17 22:40:00 GMT 2015


On 3/17/2015 5:40 PM, Yaakov Selkowitz wrote:
> On Tue, 2015-03-17 at 17:15 -0400, Ken Brown wrote:
>> On 3/17/2015 3:20 PM, Achim Gratz wrote:
>>> Ken Brown writes:
>>>> Great.  Thanks for testing.  There's probably no reason for me to
>>>> upload a new clisp package right now (unless it would help you).  But
>>>> I'll give you a heads up when I'm ready to do that.
>>>
>>> I've now drilled to the bottom of what I had assumed were build/package
>>> problems… it turns out that if you rebase the lisp.dll, then the dumped
>>> executable that depends on it stops working.
>>
>> I'll study the clisp code that creates dumped executables and see if I
>> can figure out what's going on.
>>
>>> rebase has altered lisp.dll even
>>> though it says it didn't.
>>
>> This sounds like a bug in rebase, but it probably isn't related to the
>> present problem.
>
> Do I understand correctly that lisp.exe (AKA lisp.run on *NIX platforms)
> is the only binary loading these modules, and that these modules depend
> on the symbols in lisp.exe (if there were no lisp.dll)?

Yes.  But that makes me wonder if I made things too complicated and 
could have avoided building lisp.dll.  The native Windows build of clisp 
creates a lisp.def file, containing the symbols of lisp.exe, and it just 
adds "lisp.def" to the gcc command line when building the modules.  But 
that didn't work on Cygwin; the linker complained that it didn't know 
what lisp.def was, and it tried to interpret it as a linker script.  Is 
there a way to make this approach work?

> How does the
> lisp.exe in clisp relate to the one that would be in maxima-exec-clisp?

Achim will have to answer this one.

Ken



More information about the Cygwin-apps mailing list