I've been experimenting with application delivery on various linux systems, toward the elusive goal of being able to dump an executable with SBCL that works on machines other than my own. One problem I've encountered is an ability to load reload librt on some systems (notably, the kubuntu 7 VM I'm playing in).
osicat/posix/unix.lisp contains the following library definition:
(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)
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.
On 7/3/09, Luis Oliveira luismbo@gmail.com wrote:
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?
Changing /usr/lib to /lib was random flailing around on my part. I'm not sure where it's supposed to live. On the older kubuntu VM I've been doing some tests in, it has:
/lib/librt-2.6.1.so /lib/librt.so.1 -> /lib/librt-2.6.1.so /usr/lib/librt.so -> /lib/librt.so.1
For reasons unknown to me, despite the /usr/lib/librt.so existing, it couldn't find librt until I changed it to librt.so.1.
As for distributing libraries with the executable, so far I haven't needed to (recall the strange efforts I took to avoid distributing the osicat wrapper.so), but I've just been thinking about out how to do it in order to distribute a version of libmpg123 with known compilation options. I was going to give it name (like libshuffletron-mpg123) and copy it into /usr/local/lib where it will be found automatically, but the trouble then is to also make the program runnable after untarring it without doing a 'make install'. I hadn't thought of cffi:*foreign-library-directories* but that sounds useful.
So far as CFFI is concerned, its problems at present are that it seems to forget entirely the existence of libraries loaded directly by pathname (such as wrapper.so), and these are precisely the ones that cause trouble with deployment.
-
Andy Hefner -
Luis Oliveira