<div dir="ltr"><div><div>I'm totally in favor of having dlopen work correctly everywhere as the ideal solution. However, as I said, that doesn't always happen, and this is an intermediate solution.<br></div><div><br>

I hadn't thought about the secondary library problem, that is a good point. I thought though that we were required to list all libraries needed (even dependent ones) explicitly, or is that just for SBCL? Nevertheless, my point stands: if this is a problem for my proposed solution, it is a problem as things are now, which absolute paths defined in projects that use CFFI.<br>

<br></div>Please keep in mind the proposed list is merely observational. They are culled from existing projects, and if wrong, are also wrong for those projects. Experts in the various OSes, please do propose better paths.<br>

<br></div>Liam<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 9:25 AM, Luís Oliveira <span dir="ltr"><<a href="mailto:luismbo@gmail.com" target="_blank">luismbo@gmail.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="">On Sun, Mar 30, 2014 at 2:41 PM, Liam Healy <<a href="mailto:lnp@healy.washington.dc.us">lnp@healy.washington.dc.us</a>> wrote:<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>
</div>I'm sympathetic towards the goal of making things work out-of-the-box,<br>
but I'm worried a list like this could backfire and obfuscate some<br>
issues.<br>
<br>
I'd say that, on unix systems, if dlopen() can't find libraries in<br>
/usr/lib then something is deeply wrong with that system. Most of the<br>
other paths you list look like they should be configured in ld.so.conf<br>
or similar. (I suppose we could open an exception on OS X where signed<br>
binaries have an empty lookup path for dlopen().)<br>
<br>
There is another issue. *FOREIGN-LIBRARY-DIRECTORIES* doesn't affect<br>
how the dynamic linker will look up library dependencies. So while it<br>
might find libfoo in /opt/local/lib the linker will fail to load<br>
dependencies that are also in strange places. Perhaps we can fix that,<br>
though. I suppose we can set appropriate environment variables to<br>
guide the linker.<br>
<br>
Placing the 64-bit directories on that list unconditionally seems<br>
wrong, as Martin pointed out.<br>
<br>
What do you think Liam?<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Luís Oliveira<br>
<a href="http://kerno.org/~luis/" target="_blank">http://kerno.org/~luis/</a><br>
</font></span></blockquote></div><br></div>