Re: Shared library search paths

"Oliver Elphick" wrote:
>I'm referring this back to the Debian mailing lists; perhaps this
>documentation is out of date.

Here's some responses. It seems that I shall probably have to disable
use of -rpath for the Debian build.

=========================================================================
Date: Fri, 21 Jul 2000 09:09:32 +0200
From: "J.H.M. Dassen (Ray)" <jhm(at)cistron(dot)nl>
To: debian-devel(at)lists(dot)debian(dot)org
Subject: Re: Use of -rpath

In my experience, -rpath is a big PITA. For example, Red Hat used to ship a
libc5 CDE package that was linked -rpath /usr/X11R6/lib. In that time,
Debian's X was already libc6, and libc5 versions of the X libraries were in
/usr/lib/libc5-compat. This directory was in /etc/ld.so.conf, and the
dynamic loader was smart enough to know which library to use, /except/ when
-rpath was used. The result was that a libc5 binary, compiled for libc5 X
libraris, got loaded against libc6 X libraries, and segfaulted.

Now if -rpath's semantics were changed to it adding _to the end_ of the
dynamic loader's directory search path, it might actually be useful.

Ray
=========================================================================

To: debian-devel(at)lists(dot)debian(dot)org
Subject: Re: Use of -rpath
From: Brian May <bam(at)debian(dot)org>
Date: 21 Jul 2000 17:35:39 +1000

>> From: Peter Eisentraut <peter_e(at)gmx(dot)net>
Mike> * * *
>> > libtool also refuses to link shared libraries against other
>> shared > libraries.
>>
>> I don't think so.

Mike> Peter seems clearly right on this:

Mike> guardian:~ ldd /usr/lib/libpq.so.2.0 libc.so.6 =>
Mike> /lib/libc.so.6 (0x40011000) libcrypt.so.1 =>
Mike> /lib/libcrypt.so.1 (0x400ee000) /lib/ld-linux.so.2 =>
Mike> /lib/ld-linux.so.2 (0x80000000)

That should read "libtool 1.3 refuses to link shared libraries against
other *uninstalled* shared libraries".

ie libtool 1.3 will only allow it if both libraries are installed.

libtool 1.4 will fix this serious limitation. At least, it is serious
for packages like Kerberos (both implementations), which come with
many libraries that must (read: should) link to each other in the same
source structure.

However, AFAIK, this has nothing to do with -rpath??????
=========================================================================
Date: Fri, 21 Jul 2000 09:39:43 +0200
From: "Marcelo E. Magallon" <mmagallo(at)debian(dot)org>
To: debian-devel(at)lists(dot)debian(dot)org
Subject: Re: Use of -rpath

>> Peter Eisentraut <peter_e(at)gmx(dot)net> 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
used.

> > 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
particularly:

> 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.

Greetings,

Marcelo
=========================================================================

--
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP: 1024R/32B8FAA1: 97 EA 1D 47 72 3F 28 47 6B 7E 39 CC 56 E4 C1 47
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"Greater love hath no man than this, that a man lay
down his life for his friends." John 15:13