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

[Martin Simmons]

>>>>> On Sun, 30 Mar 2014 09:41:08 -0400, Liam Healy said:
> 
> 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?

I think your proposed unix (Linux) clause assumes a Debian-style split between
32-bit and 64-bit.  This will be wrong when using a 32-bit Lisp on 64-bit
Debian/Ubuntu and also wrong when using a 64-bit Lisp on 64-bit
Fedora/RHEL/CentOS.

I'm also not sure about the Solaris cases.  It should probably be /usr/lib/64
instead of /usr/lib/amd64, though it may also be wrong to add them for a
32-bit Lisp.

__Martin