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 <mar...@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@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
