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