Re: Shared library defines a RPATH

["Michael Teichgräber" <gnubert@web.de>]

Hi,

Brian May <bam@debian.org> writes:

> Just to make sure, I created a transcript of the session, and searched
> for rpath, and the only rpaths used are in the libtool call, which get
> removed by libtool.

this is what libtool seems to do if the generated shared library does
not depend on another library that is not in a standard library path
(as /lib). But, if a library foo is linked against another (libtool)
libfoo2.la library, the -rpath is not stripped from the linker
call. In this case, during build a .libs/libfoo.so is created with an
rpath pointing to the non-installed libfoo2.so. During install the lib
is relinked with an rpath pointing to the installed libfoo2.so.

Also, when linking an executable against an .la library, rpaths will
be inserted into the executable, at least on my system using
libtool-1.4.2a and automake1.6.

According to the info pages automake always is trying to use -rpath
when linking against shared "libraries installed in some directory", I
haven't found an option to disable this.

I still don't know about a way to avoid rpaths in executables when
using libtool and automake (besides patching the libtool script). Even
when providing an LD_LIBRARY_PATH wrapper, lintian will warn about
rpaths. But as I understand lintian, its errors are considered as
policy violations, not warnings, so a solution could be to leave the
rpaths (and warnings) in and provide an LD_... wrapper.


-- 
Michael


-- 
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org