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

[Luís Oliveira]

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/