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

[Paul Jarc]

Rob Browning <address@hidden> wrote:
> This "multiple copies problem" exists with *any* app that includes its
> own shared libraries.

Right, but most of those use ld.so, so they can be handled with
-rpath.

> Granted the -rpath mechanism does fix it in some sense, but if we
> don't respect the standard LD_LIBRARY_PATH/ld.so.conf mechanism

I think the right thing is for libltdl to respect *all* of ld.so's
mechanisms, for the sake of simplicity - you won't have to worry about
which one is being used when you want to configure something to find
libraries somewhere.  Any problem that can occur with -rpath can
already occur with ld.so; any solution for ld.so ought to be usable
with (the hypothetical fixed) libltdl as well.

> I'm not sure this is a serious problem, and perhaps just mandating the
> use of guile-config fixes it, but it's something I think we should
> consider.

I really don't like such *-config programs.  If package foo links to
libraries from package bar, I want foo to find bar via a path other
than bar's installation prefix.  I set up a symlink to bar for foo to
use.  Then when I install a new version of bar (with its own unique
installation prefix), I update the symlink (atomically, even) and foo
finds the new version.

> Hmm, well at least in the past (and perhaps still), debian policy
> forbid --rpath (I presume the same as -R).

Yes.  -R is more portable.

> As I recall, the reasoning for this was that from a system
> integrator's perspective, using an rpath causes major problems.
> Libraries will need to be moved around from time to time and if you
> use rpath, you make it impossible to do this
> transparently/incrementally.

I'm a system integrator too, and I use rpath extensively.  I don't
move libraries or anything else around post-installation.


paul