Re: Ignore hardcode_direct=yes if results in static lib entry

[Ralf Wildenhues]

* Albert Chin wrote on Wed, May 17, 2006 at 06:35:06PM CEST:
> On Wed, May 17, 2006 at 05:17:54PM +0200, Ralf Wildenhues wrote:
> > * Gary V. Vaughan wrote on Wed, May 17, 2006 at 05:11:46PM CEST:
> > > Ralf Wildenhues wrote:
> > > >* Albert Chin wrote on Wed, May 17, 2006 at 03:18:09AM CEST:
> > > >
> > > >>The following patch addresses
> > > >>http://lists.gnu.org/archive/html/libtool/2006-04/msg00044.html. I
> > > >>added a new variable, hardcode_direct_static, to indicate if
> > > >>hardcode_direct=yes would hardcode a static library dependency. This
> > > >>impacts HP-UX/PA and AIX.

> > Thanks.  It would be great if you could explain that "static library
> > dependency" does _not_ have to do with static libraries at all -- what
> > a confusing name IMHO!  Maybe we should think of a better one.  Is that
> > what HP-UX is using in their documentation?
> 
> I couldn't find a name for this in the HP documentation so I made
> something up :) However, the output of 'chatr' has 'static' in the
> type of the DT_NEEDED line so that's where I came up with the name.

OK.  So let's name the thingy hardcode_direct_absolute.

I'm still not convinced this approach is right at all; here's why:
First, there are more bugs in the description: you're not going after
the fact that the absolute DT_NEEDED entry cannot be overridden by
$shlibpath_var, but that the absolute DT_NEEDED entry just isn't
overridden by any other paths, not even DT_RPATH.

Here's why: it may be possible that the system allows absolute DT_NEEDED
entries, but that shlibpath_overrides_runpath=no.  Then you're still out
of luck when trying to "relocate" stuff.  But once indirect dependencies
come into play, this issue is still important, because now you don't
only have the runpaths in that library at hand, but also those of the
objects that are already loaded and higher up in the graph.

What I'm trying to say: the current description doesn't make it clear
that from a Libtool POV these variables are orthogonal to each other.

I actually believe that the absolute DT_NEEDED is actually the normal
case with most of the systems we have hardcode_direct=yes for; I just
need some time to go check and prove that.  Then, the right fix would
be to kill this variable again and just reorder the hardcode methods
in ltmain.in.

Cheers,
Ralf