Re: Shared library search paths - Mailing list pgsql-hackers

"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@cistron.nl>
To: debian-devel@lists.debian.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@lists.debian.org
Subject: Re: Use of -rpath
From: Brian May <bam@debian.org>
Date: 21 Jul 2000 17:35:39 +1000
   >> From: Peter Eisentraut <peter_e@gmx.net>   Mike> * * *   >> > libtool also refuses to link shared libraries
againstother   >> 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@debian.org>
To: debian-devel@lists.debian.org
Subject: Re: Use of -rpath

>> Peter Eisentraut <peter_e@gmx.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
situationmight have changed...  let me check...  Nope,1.3.5 still uses -rpath whenever shared libraries are going to
beused.
> > But `-rpath' can cause big problems if the referenced> >   libraries get updated. Therefore, no Debian package
shoulduse the> >   `-rpath' option.> > I'm not sure I buy that. All -rpath does is add a directory to the search> path
thatthe 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 isinstalled.  This is hardcoded into the linked program.
Fromld.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
sharedobjects at runtime.  The `-rpath'>   option is also used when locating shared objects which are needed>   by
sharedobjects 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.  Noteparticularly:
>  The simple-minded inter-library dependency tracking code of libtool>  releases prior to 1.2 was disabled because it
wasnot clear when it>  was possible to link one library with another, and complex failures>  would occur.  A more
compleximplementation of this concept was>  re-introduced before release 1.3, but it has not been ported to all>
platformsthat libtool supports.  The default, conservative behavior>  is to avoid linking one library with another,
introducingtheir>  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.Elphick@lfix.co.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
hisfriends."      John 15:13