On Fri, Jun 12, 2009 at 01:24:34PM -0700 or thereabouts, Elliott Slaughter wrote:
I have a question about the implementation of %load-foreign-library on SBCL. It seems that the call to load-shared-object remembers the absolute pathname to the library that is loaded unless :dont-save t is used. This causes portability issues for my application, which can't load from the same path when used on different systems. Is there any reason to choose this behavior?
Of course, with :dont-save t, the user then has to call use-foreign-library again when starting up from the saved image, but I find this preferable to the crash I receive otherwise.
Hi Elliott,
I know you were asking about SBCL, but I think I have encountered a similar problem with CMUCL.
When I bound cffi:*foreign-library-directories* and then loaded a library with cffi:load-foreign-library it set up a system::*global-table* like this:
((#<System-Area-Pointer: #x0806C6E0> . "/absolute/path/to/libwhatever.so"))
When you save this image and reload it later, system::*global-table* is processed by #'reinitialize-global-table. The problem is that this will fail if libwhatever.so no longer lives in that directory when the image is reloaded.
Since I loaded a library I had just compiled before subsequently installing it to /usr/lib/, the solution was to change the value of system::*global-table* to this before saving the image:
((#<System-Area-Pointer: #x0806C6E0> . "libwhatever.so"))
That way when the image was reloaded it would search the default library path which was what I needed.
Hope this helps,
Doug
PS. reference: around CMUCL src/code/foreign.lisp:
... #+linkage-table (pushnew #'reinitialize-global-table ext:*after-save-initializations*) ...