[Cffi-devel] Pre-populate cffi:*foreign-library-directories* by OS

[Liam Healy]

>From time to time I have seen requests from users to include an absolute
path (starting from "/") in systems that use load-foreign-library under a
clause for their favorite OS. This makes me nervous, especially when it is
a little-used OS, because I have the feeling the requester's configuration
is not typical for that OS and I will later get a request to add a
different path when the original requester has moved on.

Ideally, there would never have to be any absolute paths; dlopen would
always know where to find libraries, because the OS is always configured in
a standard way. However, a quick survey of this topic shows that reality
falls far short of this ideal, and remedies are not clear. It is well
beyond our capabilities to fix the entire world on this matter.

Between fixing the world and fixing every CFFI-using application one by
one, there is the compromise of setting default search paths for each OS in
CFFI itself, thereby opening all applications to proper functionality out
of the box for most OSes. The variable cffi:*foreign-library-directories*
seems like the right thing to set. I've looked through all Quicklisp
libraries for absolute paths in uses of load-foreign-library, and found
these:

Solaris: /lib/64, /usr/lib/amd64, /usr/lib
Darwin: /usr/lib, /opt/local/lib, /usr/local/lib
Unix: /usr/local/lib, /usr/lib

Therefore I propose to change the definition to:

(defvar *foreign-library-directories*
  '(#+(or unix darwin solaris) "/usr/lib"
    #+(or unix darwin) "/usr/local/lib"
    #+darwin "/opt/local/lib"
    #+solaris "/lib/64"
    #+solaris "/usr/lib/amd64")
  "List onto which user-defined library paths can be pushed.")

As requests come in to add an absolute path for an application, they can be
referred to this mailing list to request the change here, if it is not an
application-specific path. Then it is more likely to be properly vetted for
general applicability for all users of that OS, and will be available for
all libraries. Does this sound like a reasonable way to handle this problem?

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20140330/97a972cd/attachment.html>