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

[Liam Healy]

Thanks Frank. Unfortunately it is just not true that "The OS does know how
to load libs" as much as you and I would like, based on bug reports I've
seen, patches, and my investigation of Quicklisp libraries.

Attempts to tell people to set their env or otherwise configure their
OS/install their libraries correctly usually meets with indignant
contentiousness. People load a system, get a failure on the foreign library
load, locate the define-foreign-library form, then send a request/patch to
add an absolute path for their OS. They don't want to be told to set their
environment (they may not even know what that is), they want it to work,
and they've found a way to make it work for them. My idea is to: (a) have
all the libraries work out of the box, and (b) not have to tell people to
fix their OS configuration, when it's not even well-defined how to do that
(or, at least, I don't know how to do it for their OS -- it's not always
LD_LIBRARY_PATH).

This takes care of both problems in many cases.

Liam



On Sun, Mar 30, 2014 at 12:21 PM, Frank Goenninger <frgo at me.com> wrote:

> Hi Liam,
>
> as it does not hurt to have multiple directories in
> *foreign-library-directories* I personally don't care what the entries are
> ... One of the first things I do is set it to nil .. The OS does know how
> to load libs. If someone wants to add dirs then please do this via env
> vars!!
>
> Just my two cents.
>
> Cheers
>    Frank
>
> PS I don't understand all the discussion around this. Proper env var
> setting just about cures everything.
>
> Von meinem iPhone gesendet
>
> > Am 30.03.2014 um 15:41 schrieb Liam Healy <lnp at healy.washington.dc.us>:
> >
> > 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
> > _______________________________________________
> > Cffi-devel mailing list
> > Cffi-devel at common-lisp.net
> > http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20140330/eab85a51/attachment.html>