[Cffi-devel] Pre-populate cffi:*foreign-library-directories* by OS

[Liam Healy]

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 at gmail.com> wrote:

> On Sun, Mar 30, 2014 at 2:41 PM, Liam Healy <lnp at 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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20140405/c3238509/attachment.html>