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

[Luke Crook]

Could the lisp application be packaged with a config file containing this
list? The user could the add additional directories to the load
path instead of messing with the OS.





On Sunday, March 30, 2014, Liam Healy <lnp at healy.washington.dc.us> wrote:

> 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<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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<javascript:_e(%7B%7D,'cvml','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/1affc8c4/attachment.html>