Re: [gpsd-dev] RPATH tangle

[Greg Troxel]

"Eric S. Raymond" <address@hidden> writes:

> Miroslav Lichvar <address@hidden>:
>> But I'm wondering how does automake/libtool do it. Does it ever set
>> RPATH in installed files?
>
> See this page:
>
> https://wiki.debian.org/RpathIssue
>
> It seems libtool used to screw with RPATH quite promiscuously, before
> 2004.  It doesn't any more; the Debian crew beat them mercilessly
> until they stopped.

It should be noted that this is a Debian-specific objection.  In
particular, they reject the notion that when changing a library soname
everything that depends on that library must be rebuilt.  pkgsrc takes a
different approach and requires a rebuild.  Thus, it avoids he
complexity of the games Debian plays to work around linking with two
versions.

I'm not claiming either approach is morally superior.  Just pointing out
that "Debian objects to RPATH" does not lead to "RPATH bad".   For many
other systems, it is the standard approach.

My impression has been that libtool builds binaries and libraries that
when run from the OBJDIR link against libraries for the OBJDIR, and
these are repointed on install to link against the installed libs,
enabling testing and debugging of code that is not installed.

For pkgsrc, it is more or less a requirement to run the tests without
installing the code.

I find chrpath less gross than using LD_LIBRARY_PATH.  It's really a bug
in scons that it doesn't cope with this before-install/after-install
RPATH issue; it's a clear regression from the auto*/libtool way.

That said, if one can

 "scons check" and reliably link against the just-build OBJDIR libs, and

 "scons install" and end up with binaries/libs with RPATH to
 ${PREFIX}/lib (unless PREFIX == /usr)

then I think all is ok.

pgpQvjHxs_orI.pgp
Description: PGP signature