[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Shared library defines a RPATH

On Mon, Jul 29, 2002 at 03:40:18PM +0200, Richard Atterer wrote:
> I'm still convinced that it is fine to use rpath in the following
> case:
>  - The lib referenced with rpath is in the same package as the
>    binaries that make use of it.
>  - No other binaries in any other package reference the library. 
>    (Maybe exception if the other package is closely tied to the first
>    and depends on exactly a particular version.)
>  - The lib is not intended to be used by anyone else. There's no -dev
>    package for it, it is just a convenience lib to avoid that lots of
>    related binaries contain the same code.

These arguments convinced me, at least, but I think your conditions
need to be tightened up to talk about the directory referenced by
rpath, not the specific libraries.  The entire directory needs to
be private to this package, because the RPATH attribute is used for
all library searches in that executable.  And it's not completely
possible to predict which libraries will be searched for, because
libraries can be pulled in by indirect dependencies.  So for safety,
there shouldn't be any other libraries in the rpath directory.

(Note: This also means that the whole reason for segregating these
libraries, namely avoiding name collisions, might not work.  If your
package uses a private "libdd", and the name unexpectedly collides
with for example a new audio format "Direct Drumbeats", then your
executable can still lose if the non-private libdd is pulled in by
for example libsdl.)

> Let's look at the disadvantages I've heard about so far:
>  - "rpath breaks cross-compilation": It doesn't, at least not
>    inherently. You just need to pay more attention to get things
>    right. rpath will certainly prevent "out of the box" cross-builds
>    of some programs, *but* projects that use automake should be fine.

The build script should take care to use the final installation path
in -rpath, not just the build path.  I think we already need this in
order to build non-cross-compiled Debian packages correctly.
(I have in fact seen Lintian warn about rpaths like
"/home/jrandom/packages/foo/foo-1.0/debian/tmp/..." in uploaded packages.)

Richard Braakman
"I sense a disturbance in the force"
"As though millions of voices cried out, and ran apt-get."
  (Anthony Towns about the Debian 3.0 release)

To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: