Re: DESTDIR install on hppa-hpux

[Michael Haubenwallner]

On Wed, 2009-06-03 at 20:54 +0200, Ralf Wildenhues wrote:

> > With this patch, 10 tests ("demo-nofast.test" to "depdemo-unst.test")
> > change from SKIP to PASS, and both "Simple DESTDIR install" and "DESTDIR
> > with in-package deplibs" (destdir.at) change from "expected failure" to
> > "ok", for the 32bit hppa environments marked with "*" below.
> > No other tests do change their result.

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

> > This does require to use 'chatr' in demo-hardcode.test to not get false
> > positives when testing for hardcoded path (more comments inside).
> 
> That seems like an acceptable compromise.
> 
> > 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".

> 
> > The patch has been tested in these HP-UX environments (as well as on
> > linux and aix, without any test result changes there):
> > 
> > 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).

Thank you!

/haubi/