On Thu, 29 Jan 2009 18:53:14 +0900, John Fremlin said:
cffi-wrapper has made our lives with cffi-udp very much easier. It generates small shared libraries for interfacing with C functionality that is not well specified as an ABI.
However, for Lisps that are not Allegro CL (which copies the shared objects to the deployment directory), it can be quite irritating to deploy applications because (on Lispworks and SBCL at least) the full path the generated shared object is hard-coded in the image, and the Lisp will try to reopen that file before running user code.
SBCL for example (http://www.sbcl.org/manual/Loading-Shared-Object-Files.html)
load-shared-object interacts with sb-ext:save-lisp-and-die: 1. If dont-save is true (default is NIL), the shared object will be dropped when save-lisp-and-die is called -- otherwise shared objects are reloaded automatically when a saved core starts up. Specifying dont-save can be useful when the location of the shared object on startup is uncertain.--- a/addons/cffi/grovel/grovel.lisp +++ b/addons/cffi/grovel/grovel.lisp @@ -767,7 +767,10 @@ error: (format out ";;;; This file was automatically generated by cffi-grovel.~% ;;;; Do not edit by hand.~%") (let ((*package* (find-package '#:cl)))
(format out "~%~S~%" `(cffi:load-foreign-library ,lib-file)))
(format out "~%~S~%" `(cffi:load-foreign-library'(:or ,lib-file,(file-namestring lib-file)(:default ,(pathname-name lib-file)))))) (dolist (form lisp-forms) (print form out)) (terpri out))This patch doesn't help, because once the shared objects are loaded (before delivery) the path is stored by the Lisp environment and the other paths are not used.
Any advice or suggestions?
I strongly recommend calling cffi:load-foreign-library at run time only (never before delivery). That gives you control over how the library is loaded on startup (for example reporting errors to the user).