restarts symbols are not exported in package

[Jesse Off]

The two restarts cffi::retry and cffi::use-value are not exported symbols in the cffi package.

There may be others?

[Luís Oliveira (luismbo)]

Those restarts were meant for interactive use. I hadn't anticipated they could be useful for programatic use. Are they? They are also undocumented.

(BTW, USE-VALUE is a CL symbol.)

[Jesse Off (jesseoff)]

What I'm doing is reloading cffi libs after an image restore. Some systems I've used are defining foreign libraries with hardcoded absolute paths (cl-fuse) from their build directory. I'm attempting to catch the load-foreign-library-error and fixup/redefine the foreign library and then use the cffi::retry restart.

Heres a snippet showing roughly what I'm doing now in some image restore routines. (First attempt was to just invoke-restart cffi::retry)

    (loop for lib in *cffi-libs* do
      (ignore-errors
       (handler-bind ;workaround foreign libs w/hardcoded .so file directories
           ((cffi:load-foreign-library-error
              (lambda (err)
                (let* ((name (pathname-name (caar (simple-condition-format-arguments err))))
                       (cmd `(cffi:define-foreign-library ,lib (t (:default ,name)))))
                  (eval cmd)
                  (cffi:load-foreign-library lib :search-path ld-path)))))
         (cffi:load-foreign-library lib :search-path ld-path))))

[Jesse Off (jesseoff)]

I think I have a better workaround now after discovering the foreign-library-pathname is exported. Thanks!

[Luís Oliveira (luismbo)]

Another idea is to close the foreign libraries before dumping the image and reloading them in the restart hook. That should avoid hardcoded paths altogether.

[Jesse Off (jesseoff)]

Thats actually what I'm doing. It works swell, except for cl-fuse which hardcodes an absolute path in the define-foreign-library. When I reopen, it tries to find it at the same place. I send a :search-path "/tmp/my-libs" in the load-foreign-library, but that doesn't work. Maybe it fails because it tries to find the lib and /tmp/my-libs/cl-fuse/hard/coded/dir.so and not /tmp/my-libs/dir.so? Admitted, my curiosity here is low.

I can fix it up by redefining the shared library (after first closing it) to just look for "dir.so" I'm now doing this after the close, dump, restore, and a failure on the foreign lib reload.

Granted, the whole problem is more likely owned by cl-fuse, but I'm trying to avoid forking cl-fuse, and if guessing the probability is high another system may have the same brokenness as this is one of the first ones I've tried. I'm not opposed to accumulating workaround cruft in my toplevel if it there is no functional compromise in doing so.

[Luís Oliveira (luismbo)]

The :search-path is misnamed. :-( It should instead be named :fallback-search-path or some such as it only kicks in if dlopen() fails to find the requested library. Maybe it should be improved to actually tweak dlopen()'s LD_LIBRARY_PATH (and PATH on Windows).

Since you're getting into the realm of fun, dirty hacks, what about encapsulating/wrapping load-foreign-library to catch absolute paths? (On SBCL, that's done via sb-int:encapsulate.)