Re: Shared library defines a RPATH
Brian May <bam@debian.org> writes:
> On Mon, Jul 29, 2002 at 07:28:12PM +0200, Michael Teichgräber wrote:
> > 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
>
> I get the impression (although I might be mistaken) that you are trying
> to install libraries into a non-standard path, which isn't searched for
> in the "standard[1]" /etc/ld.so.conf, so libtool feels it needs to add the
> rpath so it can locate it.
Yes, in my case it is a (yet non-Debian) package that contains some
executables that share a few libs that will be stored into
/usr/lib/<pkg>, therefore libtool's adding of rpaths'. Both
executables and libraries are in the same package.
> If, however, I am completely confused, can you please answer the
> following:
>
> Is this *.la file installed, or part of the source tree? If it
> is part of the source tree, I will assume it is part of the same
> source tree.
Yes, it is part of the same source tree, and is generated during build
of the library within that source tree.
> If this *.la file is in the source tree, where is its final destination?
> If this *.la file is installed, where was it installed?
The .la file in the source tree is used for linking the executables in
the same source tree. It is in my opinion not neccessary to install
it, but automake/libtool copy it into /usr/lib/<pkg>. (As I
understood, an installed .la file will be needed when you want to link
an executable of another package against an already installed
library.)
> I suggest filing a bug report against libtool (wishlist or
> otherwise). In libtool source, there is the variable
> "hardcode_into_libs". I would guess (but haven't tested it) that
> changing this to "no" would fix the problems, but haven't tested
> this.
I think this only will have an effect on libraries, but not on
executables. I found that modifying hardcode_libdir_flag_spec, as
Stephen Z. suggested, works (i.e. no -rpath occurs on linking) if it
is replaced by a dummy `-D' flag. This can also be done by inserting
hardcode_libdir_flag_spec="-DDONT_HARDCODE_LIBDIRS"
at the top of the package-local ltmain.sh, since this will override
the decisions made by configure based on libtool.m4 code (which will
be inserted on top of the generated libtool, before the ltmain.sh
code). But I don't know whether this probably breaks linking on other
platforms where e.g. hardcode_minus_L is used (don't know about
side-effects).
As Richard Atterer points out in a sub-thread, for packages of this
kind (such as ogle) it is likely not bad to use -rpath (the libtool
maintainers argument it would always be a good thing). If one wants to
move the libraries after installation (for cross-installing this is
not neccessary, since different `prefix' specs at configure and
install time lead to correct rpaths within the executables), one could
provide a wrapper that changes LD_LIBRARY_PATH, but this path will
only be used if the run-time linker doesn't find the needed lib within
the rpath.
Michael
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: