Re: 1.6.0 problems with libguilereadline-v-12 and fix

[Marius Vollmer]

Greg Troxel <address@hidden> writes:

> This seems broken in two ways:
> 
>   guile should look for its own libraries in exactly one place, the
>   location where it was installed.
> 
>   guile should certainly look in $(prefix)/lib

I don't agree.  While your suggestions would make it work, they would
do so with non-standard means.  The right thing is to configure your
system so that the installed libraries are visible to all programs, in
the standard way.

Your suggestions work against the usual means of managing shared
libraries, not with them.  I think we should work with them, even if
they are slightly broken.

So, in my view, the right fix is to set LD_LIBRARY_PATH or
LTDL_LIBRARY_PATH.

It would also be acceptable to change Guile to also look into the
directories from /etc/ld.so.conf on GNU/Linux, and generally to follow
the behavior of dlopen as closely as possible.  (One should also fix
ld to be consistent with ld.so.)

> So, I modified guile-readline/readline.scm to look in the right place
> (although perhaps not only in the right place).

Instead, you should configure the whole system to look into the right
places.

> On NetBSD, guile mysteriously looks in the right place:
> [...] 
>   9315 guile    CALL  open(0x48059100,0,0x48052d20)
>   9315 guile    NAMI  "/usr/foo/lib/libguilereadline-v-12.so"
>   9315 guile    RET   open 5
>   9315 guile    CALL  read(0x5,0xbfbfce3c,0x34)

The ".so" files are opened by dlopen, I think, not by ltdl_dlopen.
Does the documentation of dlopen reveal where it looks?

> env|grep foo turns up only /usr/foo/bin in PATH and /usr/foo/man in
> MANPATH.

Since you already include /usr/foo in PATH and MANPATH, why not also
put it into LD_LIBRARY_PATH?

-- 
GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3  331E FAF8 226A D5D4 E405