On 3/15/2015 2:19 PM, Yaakov Selkowitz wrote:
On Sun, 2015-03-15 at 13:37 -0400, Ken Brown wrote:
This sounds like a packaging error on my part. First of all, lisp.dll
is new with the latest clisp; it was part of my solution to the dynamic
loading problem. But from what you say, it sounds like I should put it
in /usr/bin. In fact, I should rename it to cyglisp.dll, with a
corresponding /usr/lib/liblisp.dll.a, so that applications can link
against it with '-llisp'. Would this solve the problem?
I'm not all that familiar with clisp. Is there a single binary that
loads these dynamic modules, or multiple binaries?
The only user-visible binary is /usr/bin/clisp.exe. This is essentially
a wrapper that calls /usr/lib/clisp-2.49+/base/lisp.exe with suitable
arguments. The latter is linked against
/usr/lib/clisp-2.49+/base/lisp.dll, as are all the modules. The modules
are simply DLLs that get loaded as needed via dlopen by the running
lisp.exe process. [Prior to the latest clisp release, there was no
lisp.dll, so there was no way (AFAIK) to build the modules as DLLs.]
I thought this would all work fine because lisp.dll was in the same
directory as lisp.exe. And it does work fine for users of clisp. But I
didn't think about applications like Maxima that would need to link
against lisp.dll.
I think my new proposal (with /usr/bin/cyglisp.dll and
/usr/lib/liblisp.dll.a) will work better. I don't know whether it's
best to split off libclisp and clisp-devel subpackages. Fedora has a
separate clisp-devel package, but it contains a lot of files that are
currently (and have always been) in the main clisp package on Cygwin.
At the moment, it's probably a higher priority to get something in the
distro that Achim can use to build Maxima. But I'm open to suggestion
on all of this.
Ken
