[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ignore hardcode_direct=yes if results in static lib entry
From: |
Albert Chin |
Subject: |
Re: Ignore hardcode_direct=yes if results in static lib entry |
Date: |
Wed, 17 May 2006 16:16:49 -0500 |
User-agent: |
Mutt/1.5.6i |
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)
Re: Ignore hardcode_direct=yes if results in static lib entry, Albert Chin, 2006/05/17