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 <l...@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 > <f...@me.com<javascript:_e(%7B%7D,'cvml','f...@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 >> > <l...@healy.washington.dc.us<javascript:_e(%7B%7D,'cvml','l...@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@common-lisp.net<javascript:_e(%7B%7D,'cvml','Cffi-devel@common-lisp.net');> >> > http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel >> > >
_______________________________________________ Cffi-devel mailing list Cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
