[Top][All Lists]

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

Re: first draft of "relocatable" module

From: Ralf Wildenhues
Subject: Re: first draft of "relocatable" module
Date: Mon, 26 Feb 2007 05:14:36 +0100
User-agent: Mutt/1.5.13 (2006-08-11)

* Bruno Haible wrote on Sun, Feb 25, 2007 at 09:30:59PM CET:
> Ralf Wildenhues wrote:
> > 
> > - A library was hardcoded with an absolute path, and you cannot override
> >   it at all  (e.g., DT_NEEDED contains /path/to/libfoo.so, which Libtool
> >   branch-1-5 does on OpenBSD; also I think OpenServer builds their stuff
> >   that way).
> Indeed, it would have to be documented in the user's documentation that
> the relocatable module doesn't work on OpenBSD when shared libraries are
> involved.

Well.  On systems where Libtool hardcodes an absolute soname.  1.5.22
does it, and 1.5.24 will do it, but 2.0 will not do it any more on
OpenBSD.  But there are some ancient or rarer systems where it will
still happen.

> I don't understand all the details here. Is the documentation from [1]
> correct and sufficient? It says:
>   For reliability it is best to give together with --enable-relocatable a
>   --prefix option pointing to an otherwise unused (and never used again)
>   directory,

This bit looks good.

>   for example, --prefix=/tmp/inst$$.

This bit doesn't.  Since /tmp is usually world-writable, you've got your
attack vector already.  I don't know what to suggest as a good directory
though, if you have to.

>   This is recommended
>   because on some OSes the executables remember the location of shared
>   libraries (and prefer them over LD_LIBRARY_PATH !),

Yes (except the variable is also called differently elsewhere).

>   therefore such an
>   executable will look for its shared libraries first in the original
>   installation directory and only then in the current installation directory.


> If this is not sufficient, what else can we recommend to prevent problems?
> [1] http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html

Seems ok, although I haven't looked through all of the link yet.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]