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

[Albert Chin]

On Wed, May 17, 2006 at 09:55:42PM +0200, Ralf Wildenhues wrote:
> * 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.

Ok.

> 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.

True.

> 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.

Ok, so should I contribute a new patch with the rewording?

> 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.

-- 
albert chin (address@hidden)