>>>>> 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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
