Thread: Shared library search paths

Shared library search paths

From
Peter Eisentraut
Date:
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


Re: Shared library search paths

From
"Oliver Elphick"
Date:
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



Re: [PORTS] Shared library search paths

From
Thomas Lockhart
Date:
> 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

Re: Shared library search paths

From
Peter Eisentraut
Date:
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


Re: Shared library search paths

From
"Oliver Elphick"
Date:
Peter Eisentraut wrote: >Oliver Elphick writes: > >> As far as Debian is concerned, use of rpath is a bug.  Here's a
quotefrom >> 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
isadd 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
shouldbe called the sons of God..."                                I John 3:1 
 




Re: Shared library search paths

From
"Oliver Elphick"
Date:
"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