On 3/15/2015 12:40 PM, Achim Gratz wrote:
Ken Brown writes:
My work was based on the tip of the upstream Mercurial repository,
which shows a version number of 2.49+ and is at revision 15623. So I
was thinking of using 2.49+hg15623 as the version number. Will upset
be happy with that? Or is there some other standard way of assigning
version numbers in cases like this?
Maxima needs to be rebuilt for the new clisp, but the clisp-exec build
errors out with
/mnt/share/maint/maxima.x86_64/build/src/binary-clisp/maxima.exe: error while
loading shared libraries: lisp.dll: cannot open shared object file: No such
file or directory
I'm not sure if that's a build error on the clisp side or something I
need to fix in maxima yet, but if you know what to do, please chime in.
If I link the lisp.dll from clisp into the binary-clisp directory _and_
start maxima with the cwd in that same directory I can start it. But
not if I just add to PATH. It also works if lisp.dll gets linked into
/usr/bin. So how do I tell that executable where to look for libraries
at runtime?
The clisp mem-based build runs the tests (not finished yet).
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?
In retrospect, I should have made the new clisp a test release, to avoid
breaking things. Sorry about that.
Ken