* 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. ACK. > 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. Cheers, Ralf
