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

[Martin Simmons]

The problem is that there is no general agreement about where to put libraries
on Linux and most 64-bit Linux distros support running 32-bit programs using
libraries in a different directory from the 64-bit ones.

On 32-bit Debian, /usr/lib is likely to contain 32-bit libraries.
On 64-bit Debian, /usr/lib is likely to contain 64-bit libraries.
On 32-bit and 64-bit Fedora, /usr/lib is likely to contain 32-bit libraries.

Many libraries on later Ubuntu distros are in platform-specific directories
such as /usr/lib/i386-linux-gnu and /usr/lib/x64_x86-linux-gnu

Therefore, the path you need depends on whether you are running a 64-bit Lisp,
a 64-bit OS and also on which distro you are running.  In particular, /usr/lib
might give you the wrong libraries.

__Martin


>>>>> On Sat, 5 Apr 2014 16:48:31 -0400, Liam Healy said:
> 
> I'm uncertain what you mean, all that #+unix adds is /usr/lib and
> /usr/local/lib. How is that Debian-specific? Can you suggest better paths
> for #+unix, or #+linux if you want? I noticed the Solaris "64" and "amd64"
> inconsistency, but I'm not a user of Solaris so I don't know what's right.
> 
> Moreover: all those paths come from actual paths used in quicklisp
> projects. Presumably, if it works for users of those projects, it works for
> all users of all projects on those platforms. Conversely, if it doesn't
> work, it needs to be fixed everywhere. This supports the idea of putting it
> in a central place; it is already getting more visibility than the
> discussions on project mailing lists.
> 
> 
> On Mon, Mar 31, 2014 at 1:24 PM, Martin Simmons <martin at lispworks.com>wrote:
> 
> > >>>>> 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
> >
> > _______________________________________________
> > Cffi-devel mailing list
> > Cffi-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
> >
>