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

[Marius Vollmer]

address@hidden (Paul Jarc) writes:

> Marius Vollmer <address@hidden> wrote:
> > I really do strongly believe that when you install software into
> > /usr/local but the system can't find shared libraries in
> > /usr/local/lib by default, then the system is not correctly
> > configured, not the package that has been installed into /usr/local.
> > Same with any other prefix.
> 
> Ok, but my way of configuring the system to find those libraries is to
> use ld -R.  If libltdl is fixed to look in such directories, then each
> admin gets to choose whether to use -R or LD_LIBRARY_PATH on their own
> systems, so everybody's happy.  Right?

Yep, definitely.  I just checked, and dlopen on GNU/Linux seems to
respect "-R" and since libltdl falls back on the native dlopen, you
should be fine.  I think that bugs in libltdl have prevented it from
falling back gracefully, but you should have a fixed libltdl soon.

With the fixed libltdl, my Guile 1.6.0 installation in /usr/local/ can
find libguilereadline-v-12.so in /usr/local/lib even when
/usr/local/lib is neither in /etc/ld.so.conf nor in LD_LIBRARY_PATH
(or any other env var).

(We still ahve the problem that we can't currently specify a interface
number of major version to load-extension, but you hack around tis for
the time being by including the major version in the library name
itself.)

> I'm not asking for Guile to automatically supply -R${libdir}.  I can
> add that to LDFLAGS myself, and those who don't like that way of
> doing things can leave it out.  But I would like for -R${libdir} to
> be used by libltdl, if I supply it.

This will be the case in 1.6.1, at least with the GNU libc.

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