ltdl system search path hardcoded at build

[Daniel Reed]

Libtool 1.5.10's ltdl.m4 includes the code:
  AC_DEFINE_UNQUOTED(LTDL_SYSSEARCHPATH, "$sys_search_path",
    [Define to the system default library search path.])

This causes the macro LTDL_SYSSEARCHPATH to hold the value of what was
originally sys_lib_dlsearch_path_spec in libtool.m4.

sys_lib_dlsearch_path_spec is set to "/lib /usr/lib" by default and is
modified by some environment-specific checks. For Linux ELF,
sys_lib_dlsearch_path_spec is reset to "/lib /usr/lib" plus the contents of
/etc/ld.so.conf (see the "libtool-1.5.10.ldsoinclude.patch" thread on
libtool-patches).

The macro LTDL_SYSSEARCHPATH, set based on the contents of /etc/ld.so.conf
at build time, is used by ltdl's try_dlopen routine as a path in which to
search for unpathed files.

Without libtool-1.5.10.ldsoinclude.patch, on systems that use recent glibc's
"include X" form, lt_dlopenext("test") would cause the application to
attempt to
        open("/lib/libtest.la")
        open("/usr/lib/libtest.la")
        open("include/libtest.la")
        open("ld.so.conf.d/*.co/libtest.la")
        open("/usr/X11R6/lib/libtest.la")
and so on.

However (and unrelated to the ldsoinclude problem), in environments where
the build system is not the same as the host system, as in situations where
a library or executable may be built on a single-purpose mass build system
and then used on many heterogeneous systems, the contents of /etc/ld.so.conf
at build time may not exactly match the contents at run time. In situations
where build=host but a library or executable is built and then
/etc/ld.so.conf is changed (by the installation or removal of another
package, or by manual intervention), the contents at build time again do not
match the contents at run time.


My understanding is that the $sys_lib_dlsearch_path_spec variable is used
for two main purposes: Culling the list of -rpaths to embed in a target; and
seeding the search path used by ltdl.

For the former case, $sys_lib_dlsearch_path_spec must be a subset of the
paths used by ld.so to find libraries. That is, culling a library from the
explicit -rpath list would cause the build to succeed but the running to
fail. (sys_lib_dlsearch_path_spec is used to list the libraries *not* to
explicitly search because the system will search them for us.)

For the latter case, $sys_lib_dlsearch_path_spec must be a supserset of the
paths used by dlopen() to find modules. (sys_lib_dlsearch_path_spec is used
to list the libraries *to* explicitly search because we want to mimick the
system's behavior in finding .so files to find .la files.)

On Linux, at least, it is my understanding that the paths used by ld.so to
find libraries and the paths used by dlopen() to find modules are the same;
hence $sys_lib_dlsearch_path_spec must be a subset and a superset of this
list. The only set that is both a subset and a superset of an original set
is the original set itself; hence $sys_lib_dlsearch_path_spec must be
exactly the correct set in every situation.


1) It may be useful to add a command-line argument to libtoolized
./configure scripts to list an override value for sys_lib_dlsearch_path_spec
for one or both of its uses.

2) My understanding is that there is no plan to introduce a command line
argument to ldconfig to extract the library search path as ld.so will see
it. However, it may be useful to request this if it is deemed necessary. In
addition to a command line argument to ldconfig, it might be useful to
request an accessible glibc function to return the search path at run time
for ltdl's use.

3) Parsing /etc/ld.so.conf within Libtool may be discouraged because the
format of /etc/ld.so.conf is not fixed, and the format is keyed off of the
version of glibc installed. The libtool-1.5.10.ldsoinclude.patch patch does
not exactly mimick glibc-current's ld.so.conf-parsing behavior; it simply
adds enough functionality to Libtool's ld.so.conf parser to work in the
[currently] common case.

It may be useful to change the behavior so that sys_lib_dlsearch_path_spec
reverts to only being "/lib /usr/lib", even on Linux ELF. We would have to
live with "unnecessary" -rpath linkings and the stipulation that lt_dlopen()
users must give an explicit search path during their initialization for
anything not in /lib or /usr/lib (even if it's in /etc/ld.so.conf and even
if dlopen("module.so") works while lt_dlopen("module.la") does not). This
could be more acceptable if one or both of the other options are also
adopted.


(This started as a bug report but it seems more like an RFC now.)

-- 
Daniel Reed <address@hidden>    http://people.redhat.com/djr/   
http://naim.n.ml.org/
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all progress
depends on the unreasonable man. -- George Bernard Shaw