* Michael Haubenwallner wrote on Thu, Jun 04, 2009 at 01:35:11PM CEST: > On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote: > > > > The most important part of the fix is already suggested in comments > > > around 'hardcode_minus_L=yes', as the encoded library path is used as > > > fallback location for a specific library when runpath lookup fails. > > > As this isn't really 'hardcoding' in libtool's sense, hardcode_minus_L > > > can safely be set to 'no' IMO, opening the door for DESTDIR support. > > > > Hmm. This does open a small security issue, no? Imagine the following > > setup: user joe compiles some package, then uses 'sudo make install' to > > install it in a system location. First issue: the path to the > > compilation location is revealed in the installed libraries and programs > > which have dependencies to newly-installed libraries. Second, if those > > deplibs are removed for whatever reason, then the runtime linker will > > search in joe's build tree for the shared libraries. This may not be > > likely to happen, but it's something to think about. > > I've thought about this too, but how would the link command have to look > like to avoid this issue?
I don't know. That's precisely the reason we haven't gone this way before. > > > Another minor one was that there is no need to pass > > > "+b $install_libdir", as the linker ignores subsequent "+b" values. > > > > Erm, libtool has code to merge multiple run path values (and to let > > ltmain know that this needs to be done). Weren't semantics on HP-UX > > that way that, if +b was not used, then the linked path with -L is > > searched too? That would be bad then. > > This is done anyway using $hardcode_libdir_flag_spec. > Leaving "+b $install_libdir" in $archive_cmds would ignore the > subsequent collected "+b $libdir". Oh. So I guess this would be an independent fix anyway? > > > arch HP-UX bits * compiler > > > ------------------------------ > > > What does this table mean? That for each of the combinations, the > > libtool testsuite was run, > > Exactly. > > > and there were no failures? > > Well, there weren't _no_ failures, but the same failures compared to > vanilla git/master, except for the 12 tests changing from SKIP or XFAIL > to PASS (see above). Cool. Thank you. Cheers, Ralf