[cffi-devel] %load-foreign-library on SBCL

[doug at hcsw.org]

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*)
...