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

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

[Paul Jarc]

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.)

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
access("/lib/libguilereadline.so", R_OK) = -1 ENOENT (No such file or directory)
open("/lib/libguilereadline.so", O_RDONLY) = -1 ENOENT (No such file or directory)


paul

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

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

[Paul Jarc]

I wrote:
> When I evaluate (use-modules (ice-9 readline)), guile search only /lib
> when looking for libguilereadline.so (not even /usr/lib).

More info: if I create a symlink in /lib for libguilereadline.so, then
it will continue searching in /usr/lib after /lib.  It seems to search
all directories until the first failure instead of until the first
hit.  If I create symlinks in both /lib and /usr/lib, then it looks in
those directories and then the -rpath directories:
access("/lib/libguilereadline.so", R_OK) = 0
access("/usr/lib/libguilereadline.so", R_OK) = 0
open("/package/host/localhost/guile-1.4.1-1/conf/readline/lib/libguilereadline.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/package/host/localhost/guile-1.4.1-1/conf/ncurses/lib/libguilereadline.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/package/host/localhost/guile-1.4.1-1/lib/libguilereadline.so", O_RDONLY) = 4

Those readline/lib and ncurses/lib directories were given as -rpath
directories via LDFLAGS.

All that was with 1.4.1.  With 1.5.6, it looks for libguilereadline.la
instead of libguilereadline.so, it skips the access() calls, and
stops searching after the first open() succeeds.  So I guess this is a
libtool issue, and the situation seems to be improving, but it would
still be nice if guile could tell libtool where to look for
libguilereadline.la, since it's known to be in PREFIX/lib.


paul

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

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Tue, 18 Jun 2002 12:02:21 -0400

   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.)

   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
   access("/lib/libguilereadline.so", R_OK) = -1 ENOENT (No such file or directory)
   open("/lib/libguilereadline.so", O_RDONLY) = -1 ENOENT (No such file or directory)

yeah, 1.4.1 tries to follow the nascent conventions cobbled together in
1.6.x and HEAD, which require these kinds of env var weirdness.  the fix
is to install libguilereadline et al "internally" (under $pkglibdir) and
reference them directly.

personally, i use as ~/bin/guile for now (until 1.4.2 release):

 #!/bin/bash
 # (prefix is /tmp/a/b/c)
 export LD_LIBRARY_PATH=/tmp/a/b/c/lib:$LD_LIBRARY_PATH
 export PATH=/tmp/a/b/c/bin:$PATH
 exec guile "$@"

could you post platform info?

thi

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

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Tue, 18 Jun 2002 13:57:39 -0400

   but it would still be nice if guile could tell libtool where to look
   for libguilereadline.la, since it's known to be in PREFIX/lib.

yes.  btw, another (smaller scope) fix would be to munge readline.scm
`dynamic-link' call.

thi

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

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

[Paul Jarc]

Thien-Thi Nguyen <ttn@giblet.glug.org> wrote:
> the fix is to install libguilereadline et al "internally" (under
> $pkglibdir) and reference them directly.

So in a future version, this will Just Work?

> could you post platform info?

Linux 2.4.18, glibc 2.2.5, ncurses 5.2, readline 4.2a, gcc 3.1,
binutils 2.12, all built locally from unpatched source.  See
<URL:http://multivac.cwru.edu./sptools/> if you're curious about the
weird paths.


paul

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

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

[Thien-Thi Nguyen]

   From: prj@po.cwru.edu (Paul Jarc)
   Date: Tue, 18 Jun 2002 14:13:42 -0400

   So in a future version, this will Just Work?

yes.  to be fair, the 1.6.x and HEAD approach Just Works too (that is,
for now, i'm not so sure about future robustness in the face of
ambiguous interfaces and growing libdir pollution); i screwed up the
1.4.1 adaptation of that approach by not changing readline.scm
`dynamic-link' arg appropriately.  there is a TODO item to document
these things.

   <URL:http://multivac.cwru.edu./sptools/>

i'm glad to see more packagers and distributors of free software.

thi

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

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

[Marius Vollmer]

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