Re: hardcode_direct_absolute description

[Ralf Wildenhues]

Hi Bruno,

* Bruno Haible wrote on Wed, May 24, 2006 at 02:48:31PM CEST:
> 
> Albert Chin-A-Young pointed me to this description of hardcode_direct_absolute
> in the libtool CVS:
> 
> _LT_TAGDECL([], [hardcode_direct_absolute], [0],
>     [Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
>     DIR into the resulting binary and the resulting library dependency is
>     "absolute", i.e impossible to change by setting ${shlibpath_var} if the
>     library is relocated])
> 
> The phrase "hardcodes DIR into the resulting binary" is misleading,

Yes.

> because
> 
> 1) This hardcoding affects only the given library dependency, not other
>    library dependencies. See execution trace below. In other words, it 
> hardcodes
>    the file name DIR/libNAME${shared_ext} in the resulting binary.

Right.

> 2) If DIR is a relative pathname, it is first made absolute before being
>    hardcoded in the binary. In other words, it's not DIR/libNAME${shared_ext}
>    which is hardcoded, but `cd DIR && pwd`/libNAME${shared_ext}.

Now, *that* is yet another question.  Some systems allow you to hardcode
relative paths (see $ORIGIN on Solaris, for example).  We don't use
this variable for Solaris, but I don't like its semantics anyway.

And several systems are missing this flag.  And we don't currently have
a test to prove that the setting for this flag is right or wrong.

> I would therefore suggest to change this description to
> 
> _LT_TAGDECL([], [hardcode_direct_absolute], [0],
>     [Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
>     the absolute filename `cd DIR && pwd`/libNAME${shared_ext} into the 
> resulting
>     binary and the resulting library dependency is "absolute", i.e impossible 
> to
>     change by setting ${shlibpath_var} if the library is relocated])

That's not good either: the question whether $shlibpath_var overrides
the runpath or not is mostly orthogonal to whether the library lookup
depends on the runpath of this library (and possibly previously
libraries in a dependency chain), so really it is very misleading here.

This whole issue isn't thought through very well IMVHO.  It's quite
likely that a better solution would be to kill it again, but then
reorder the hard-coding methods, so that direct hardcoding is not
preferred to runpath hardcoding for installed libraries.

But thinking this through requires time and testing.
(I will only start looking into it after Autoconf-2.60 is out, FWIW.)

Cheers,
Ralf