Re: first draft of "relocatable" module

[Bruno Haible]

Ralf Wildenhues wrote:
> > The wrapper
> > +sets the environment variable that controls shared library searching
> > +(usually @env{LD_LIBRARY_PATH}) and then invokes the real executable.
> 
> The problem is here that this is not always possible.  There are two
> failure scenarios (at least):
> 
> - 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.

> - A library was hardcoded with an absolute path, which you may or may
>   not be able to override, but which still be searched.  This can happen
>   as DT_NEEDED entry (e.g., on HP-UX/PA) or as DT_RPATH entry
>   (most systems that have DT_RPATH).  This may or may not be considered
>   a feature of your module, but I think it should be mentioned.
> - The second possibility can have the variable take precedence (e.g.,
>   Gentoo GNU/Linux, or Darwin), or the internal path (e.g., most
>   GNU/Linux variants), or can be configured on a per-binary basis
>   (e.g., HP-UX).  In the second or third cases, relocating an installed
>   program just to install a different version (with possibly
>   incompatible libraries) into the old location of the first may lead
>   to trouble.

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, for example, --prefix=/tmp/inst$$. This is recommended
  because on some OSes the executables remember the location of shared
  libraries (and prefer them over LD_LIBRARY_PATH !), 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?

Bruno

[1] http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html