Re: (dynamic-link) ignores PREFIX/lib and $LD_LIBRARY_PATH

[Marius Vollmer <mvo@zagadka.ping.de>]

prj@po.cwru.edu (Paul Jarc) writes:

> I have guile 1.4.1 installed in an unusual place, so PREFIX/lib
> isn't in the usual search path for shared libraries.  It seems guile
> should always search PREFIX/lib, preferably before the systemwide
> directories and after those listed in $LD_LIBRARY_PATH.  (Actually,
> it should search all the -rpath directories that the binary was
> linked with, which should (and does) include PREFIX/lib.)

The best way to get around this, in my opinion, is to add PREFIX/lib
to the usual search path, system wide (or user wide).

Having a per-application or per-library search path will lead to a
hard to understand system, I'd say.  It is better to configure your
system so that there is one single shared library namespace.  Of
course, this namespace can also be configured per-user, or a user
might have multiple such namespaces that he switches between, but
making a program switch to a different namespace is likely not really
helpful in the end.

Configuring a Unix system for installation prefixes beyond /, /usr,
and /usr/local is not something that a program should attempt to do on
its own and behind the back of the sysadmin.

> When I evaluate (use-modules (ice-9 readline)), guile search only
> /lib when looking for libguilereadline.so (not even /usr/lib).  If I
> set $LD_LIBRARY_PATH to include PREFIX/lib, then guile looks there
> first and finds it, but keeps looking anyway and still fails:
>
> access("/package/host/localhost/guile-1.4.1-1/lib/libguilereadline.so", R_OK) = 0

Holy shamoly, this is a bug in libltdl (the portable dlopen wrapper
that Guile uses).

When libltdl opens a ".so" file, it uses access to test for file
readability, but it gets the interpretation of the return value wrong!

    static int
    find_handle_callback (filename, data, ignored)
         char *filename;
         lt_ptr data;
         lt_ptr ignored;
    {
      lt_dlhandle  *handle	= (lt_dlhandle *) data;
      int		found	= access (filename, R_OK);

      /* Bail out if file cannot be read...  */
      if (!found)
        return 0;

      /* Try to dlopen the file, but do not continue searching in any
         case.  */
      if (tryall_dlopen (handle, filename) != 0)
        *handle = 0;

      return 1;
    }

As you can see, access is supposed to return non-zero for a readable
file, but it does of course return zero in this case.  I'd also say
that it should use F_OK instead of R_OK since we only want to know
whether it exists.  Missing r bits should be reported when trying to
read it.

When opening a ".la" file, libltdl uses fopen to test for 'existence'.

Guile 1.5.6 links "libguilereadline" and relies on libltdl to supply
the right extension (which will be ".la").  Guile 1.4.1 explicitely
links "libguilereadline.so" and thus triggers the bug.


You can check this by executing

    (dynamic-link "libguilereadline")

and 

    (dynamic-link "libguilereadline.so")

CVS libtool has a fix for this, but it's not in a released version as
far as I know.  We'll make sure that 1.6 will be released with a good
libltdl.

Thanks for the report!

_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://mail.gnu.org/mailman/listinfo/bug-guile