Shared library search paths

For the SGI Irix 6.5, "man ld" gives:

....

-rpath library_path
Adds the library_path to the search path for DSOs. Each
library path is appended to the list of directories at the
time the executable or DSO is loaded. This option directs
rld(5) to look in the named directories, but to look only
for DSOs, and to stop looking when the correct one is found.

This option can be specified only when the -shared or
-call_shared options are also in effect. For more
information, see the rld(5) man page. (C, C++, F77, F90)

....

-shared Produces a DSO, creates all of the tables for run-time
linking, and resolves references to other specified shared
objects. The object created can be used by the linker to
make dynamic executables. (C, C++, F77, F90)

....

Hope this helps.
Mark

Peter Eisentraut wrote:

Some platforms (OSF/cc, HPUX) are already using -rpath or equivalent, so
you don't have to specify a shared library search path at runtime. I think
that a lot more platforms could use this. Can people comment on whether
and how it works on their platform? Essentially,

LDFLAGS+=-rpath '$(libdir)'

might do the trick for most.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

--
Mark Dalphin email: mdalphin@amgen.com
Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
One Amgen Center Drive +1-805-375-0680 (home)
Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)

Peter Eisentraut wrote:

Some platforms (OSF/cc, HPUX) are already using -rpath or equivalent, so
you don't have to specify a shared library search path at runtime. I think
that a lot more platforms could use this. Can people comment on whether
and how it works on their platform? Essentially,

LDFLAGS+=-rpath '$(libdir)'

might do the trick for most.

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. But `-rpath' can cause big problems if the referenced
libraries get updated. Therefore, no Debian package should use the
`-rpath' option.

libtool also refuses to link shared libraries against other shared
libraries. Debian packages have to at least link against libc (with
"-lc"), so that the dynamic linker knows whether to use the
libc5-compat libraries or not.

--
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
========================================
"For God so loved the world, that he gave his only
begotten Son, that whosoever believeth in him should
not perish, but have everlasting life." John 3:16

for all the stuff I'm doign lately, I just do:

setenv LDFLAGS "-R/usr/local/pgsql/lib -R/usr/local/lib"

and let configure handle the rest ...

On Tue, 18 Jul 2000, Mark Dalphin wrote:

For the SGI Irix 6.5, "man ld" gives:

....

-rpath library_path
Adds the library_path to the search path for DSOs. Each
library path is appended to the list of directories at the
time the executable or DSO is loaded. This option directs
rld(5) to look in the named directories, but to look only
for DSOs, and to stop looking when the correct one is found.

This option can be specified only when the -shared or
-call_shared options are also in effect. For more
information, see the rld(5) man page. (C, C++, F77, F90)

....

-shared Produces a DSO, creates all of the tables for run-time
linking, and resolves references to other specified shared
objects. The object created can be used by the linker to
make dynamic executables. (C, C++, F77, F90)

....

Hope this helps.
Mark

Peter Eisentraut wrote:

Some platforms (OSF/cc, HPUX) are already using -rpath or equivalent, so
you don't have to specify a shared library search path at runtime. I think
that a lot more platforms could use this. Can people comment on whether
and how it works on their platform? Essentially,

LDFLAGS+=-rpath '$(libdir)'

might do the trick for most.

--
Peter Eisentraut Sernanders v���g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

--
Mark Dalphin email: mdalphin@amgen.com
Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
One Amgen Center Drive +1-805-375-0680 (home)
Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)

Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Some platforms (OSF/cc, HPUX) are already using -rpath or equivalent, so
you don't have to specify a shared library search path at runtime. I think
that a lot more platforms could use this. Can people comment on whether
and how it works on their platform? Essentially,
LDFLAGS+=-rpath '$(libdir)'

For linux (at least gcc 2.7.x and 2.95.2 systems):

if specified in the compilation step,

-Wl,-rpath $(libdir)

or if specified directly to the linker

-rpath $(libdir)

- Thomas

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

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

hard-coded into dynamic linker
/etc/ld.so.conf
LD_LIBRARY_PATH

but it's the terminally accurate alternative.

What does happen if the referenced library gets updated? Nothing. -rpath
doesn't reference any libraries, it just suggests to the runtime linker
where it might look for one. I don't want to use it to find system
libraries, I just want psql to find libpq, and the right libpq, and I want
to relieve installers from having to fiddle around with these settings.

libtool also refuses to link shared libraries against other shared
libraries.

I don't think so.

--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden

Peter Eisentraut wrote:

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

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.

I'm referring this back to the Debian mailing lists; perhaps this
documentation is out of date.

--
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
========================================
"Behold, what manner of love the Father hath bestowed
upon us, that we should be called the sons of God..."
I John 3:1

"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 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@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 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.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 his friends." John 15:13