[cffi-devel] librt soname

[Luis Oliveira]

Andy Hefner <ahefner at 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.

-- 
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/