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.

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.

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.

Liam


On Thu, Apr 3, 2014 at 9:25 AM, Luís Oliveira <luismbo@gmail.com> wrote:
On Sun, Mar 30, 2014 at 2:41 PM, Liam Healy <lnp@healy.washington.dc.us> wrote:
> 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.")

I'm sympathetic towards the goal of making things work out-of-the-box,
but I'm worried a list like this could backfire and obfuscate some
issues.

I'd say that, on unix systems, if dlopen() can't find libraries in
/usr/lib then something is deeply wrong with that system. Most of the
other paths you list look like they should be configured in ld.so.conf
or similar. (I suppose we could open an exception on OS X where signed
binaries have an empty lookup path for dlopen().)

There is another issue. *FOREIGN-LIBRARY-DIRECTORIES* doesn't affect
how the dynamic linker will look up library dependencies. So while it
might find libfoo in /opt/local/lib the linker will fail to load
dependencies that are also in strange places. Perhaps we can fix that,
though. I suppose we can set appropriate environment variables to
guide the linker.

Placing the 64-bit directories on that list unconditionally seems
wrong, as Martin pointed out.

What do you think Liam?

--
Luís Oliveira
http://kerno.org/~luis/