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?