<div dir="ltr"><div>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. <br>
<br></div>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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Mar 31, 2014 at 1:24 PM, Martin Simmons <span dir="ltr"><<a href="mailto:martin@lispworks.com" target="_blank">martin@lispworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">>>>>> On Sun, 30 Mar 2014 09:41:08 -0400, Liam Healy said:<br>
><br>
> From time to time I have seen requests from users to include an absolute<br>
> path (starting from "/") in systems that use load-foreign-library under a<br>
> clause for their favorite OS. This makes me nervous, especially when it is<br>
> a little-used OS, because I have the feeling the requester's configuration<br>
> is not typical for that OS and I will later get a request to add a<br>
> different path when the original requester has moved on.<br>
><br>
> Ideally, there would never have to be any absolute paths; dlopen would<br>
> always know where to find libraries, because the OS is always configured in<br>
> a standard way. However, a quick survey of this topic shows that reality<br>
> falls far short of this ideal, and remedies are not clear. It is well<br>
> beyond our capabilities to fix the entire world on this matter.<br>
><br>
> Between fixing the world and fixing every CFFI-using application one by<br>
> one, there is the compromise of setting default search paths for each OS in<br>
> CFFI itself, thereby opening all applications to proper functionality out<br>
> of the box for most OSes. The variable cffi:*foreign-library-directories*<br>
> seems like the right thing to set. I've looked through all Quicklisp<br>
> libraries for absolute paths in uses of load-foreign-library, and found<br>
> these:<br>
><br>
> Solaris: /lib/64, /usr/lib/amd64, /usr/lib<br>
> Darwin: /usr/lib, /opt/local/lib, /usr/local/lib<br>
> Unix: /usr/local/lib, /usr/lib<br>
><br>
> Therefore I propose to change the definition to:<br>
><br>
> (defvar *foreign-library-directories*<br>
> '(#+(or unix darwin solaris) "/usr/lib"<br>
> #+(or unix darwin) "/usr/local/lib"<br>
> #+darwin "/opt/local/lib"<br>
> #+solaris "/lib/64"<br>
> #+solaris "/usr/lib/amd64")<br>
> "List onto which user-defined library paths can be pushed.")<br>
><br>
> As requests come in to add an absolute path for an application, they can be<br>
> referred to this mailing list to request the change here, if it is not an<br>
> application-specific path. Then it is more likely to be properly vetted for<br>
> general applicability for all users of that OS, and will be available for<br>
> all libraries. Does this sound like a reasonable way to handle this problem?<br>
<br>
</div></div>I think your proposed unix (Linux) clause assumes a Debian-style split between<br>
32-bit and 64-bit. This will be wrong when using a 32-bit Lisp on 64-bit<br>
Debian/Ubuntu and also wrong when using a 64-bit Lisp on 64-bit<br>
Fedora/RHEL/CentOS.<br>
<br>
I'm also not sure about the Solaris cases. It should probably be /usr/lib/64<br>
instead of /usr/lib/amd64, though it may also be wrong to add them for a<br>
32-bit Lisp.<br>
<span class="HOEnZb"><font color="#888888"><br>
__Martin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Cffi-devel mailing list<br>
<a href="mailto:Cffi-devel@common-lisp.net">Cffi-devel@common-lisp.net</a><br>
<a href="http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel" target="_blank">http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel</a><br>
</div></div></blockquote></div><br></div>