[cffi-devel] The use of wrappers in deployed applications

[John Fremlin]

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?