This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: Question about clisp version naming
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Sun, 15 Mar 2015 17:40:30 +0100
- Subject: Re: Question about clisp version naming
- Authentication-results: sourceware.org; auth=none
- References: <5500B536 dot 4050108 at cornell dot edu>
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).
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs