Andy Hefner ahefner@gmail.com writes:
(define-foreign-library librt (:linux (:or "librt.so" "/usr/lib/librt.so"))) (use-foreign-library librt)
Despite my uncertain understanding of the rules for shared library naming (and for that matter, where librt is expected to reside), I think the following definition is preferable:
(define-foreign-library librt (:linux (:or "librt.so.1" "/lib/librt.so.1"))) (use-foreign-library librt)
It used to be librt.so.1, but it was changed to librt.so, not sure why. Is there any system where "librt.so.1" doesn't work but "/lib/librt.so.1" would?
Wouldn't (:or "librt.so" "librt.so.1") work best?
By the way, I've been thinking off and on about how to handle this library reloading business automatically.
Would two new CFFI functions -- PREPARE-LIBRARIES-FOR-DELIVERY and RELOAD-LIBRARIES -- be enough for most delivery purposes? The former would close all the open libraries and store them somewhere so that the former can reopen them later when loading the core.
Not all Lisps seem to offer equivalents to sb-ext:*save-hooks* and sb-ext:*init-hooks*, but in those that do we could could even push those two functions in there.
I suppose there's the question of what to do with libraries distributed with the executable since that dlopen() won't find those on its own and we need to bind cffi:*foreign-library-directories* to something appropriate (E.g. osicat's wrapper.so.) Something like (pushnew '(merge-pathnames #p"libs/" (get-core-pathname)) *foreign-library-directories*) would work since, similarly to ASDF:*CENTRAL-REGISTRY*, the elements of *FOREIGN-LIBRARY-DIRECTORIES* are quasi-evaluated[1]. How are you dealing with that right now?
Cheers,
[1] Ugh, or they would be if a call to MINI-EVAL weren't missing in FIND-FILE in libraries.lisp.