Re: Use of -rpath
>> Peter Eisentraut <firstname.lastname@example.org> writes:
> > As far as Debian is concerned, use of rpath is a bug. Here's a quote from
> > some Debian system documentation:
> > libtool automatically inserts `-rpath' settings when compiling your
> > program.
> I don't think so.
Nowadays the situation might have changed... let me check... Nope,
1.3.5 still uses -rpath whenever shared libraries are going to be
> > But `-rpath' can cause big problems if the referenced
> > libraries get updated. Therefore, no Debian package should use the
> > `-rpath' option.
> I'm not sure I buy that. All -rpath does is add a directory to the search
> path that the program consults at runtime for its shared libraries. So
> it's just an alternative in place of
The rpath in the library tells the linker where the library is
installed. This is hardcoded into the linked program. From ld.info:
> Add a directory to the runtime library search path. This is used
> when linking an ELF executable with shared objects. All `-rpath'
> arguments are concatenated and passed to the runtime linker, which
> uses them to locate shared objects at runtime. The `-rpath'
> option is also used when locating shared objects which are needed
> by shared objects explicitly included in the link; see the
> description of the `-rpath-link' option. If `-rpath' is not used
> when linking an ELF executable, the contents of the environment
> variable `LD_RUN_PATH' will be used if it is defined.
This is particularly nasty when you -rpath things like /usr/lib.
> > libtool also refuses to link shared libraries against other shared
> > libraries.
> I don't think so.
He's right. See (libtool.info)Inter-library dependencies. Note
> The simple-minded inter-library dependency tracking code of libtool
> releases prior to 1.2 was disabled because it was not clear when it
> was possible to link one library with another, and complex failures
> would occur. A more complex implementation of this concept was
> re-introduced before release 1.3, but it has not been ported to all
> platforms that libtool supports. The default, conservative behavior
> is to avoid linking one library with another, introducing their
> inter-dependencies only when a program is linked with them.
i.e., you have to ask libtool to do this, else it won't.