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 ([EMAIL PROTECTED])
