Re: DESTDIR install on hppa-hpux

[Ralf Wildenhues]

Hello Michael,

* Michael Haubenwallner wrote on Wed, May 27, 2009 at 12:16:59AM CEST:
> 
> now I've managed to get 'make install DESTDIR=...' working on
> hppa-hpux10 and hppa-hpux11 with libtool.

Cool.

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

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

> 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
> ------------------------------
> hppa  10.20  32  * gcc-3.0.1
> hppa  10.20  32  * HP C Compiler A.10.32.30 (with CXX=false)
> 
> hppa  11.11  32  * gcc-3.3.4
> hppa  11.11  32  * "HP C Compiler PHCO_27774" + "HP ANSI C++ A.03.52"
> hppa  11.11  64    "HP C Compiler PHCO_27774" + "HP ANSI C++ A.03.52"
> 
> ia64  11.23  32    gcc-4.2.4
> ia64  11.23  32    HP aC++/ANSI C A.06.10 (both cc/aCC)
> ia64  11.23  64    gcc-4.2.4
> ia64  11.23  64    HP aC++/ANSI C A.06.10 (both cc/aCC
> 
> hppa  11.31  32  * gcc-4.3.1
> hppa  11.31  32  * "HP C Compiler PHCO_27774" + "HP ANSI C++ A.03.85"
> hppa  11.31  64    "HP C Compiler PHCO_27774" + "HP ANSI C++ A.03.85"

What does this table mean?  That for each of the combinations, the
libtool testsuite was run, and there were no failures?

I haven't looked at the patch in detail yet.

Thanks!
Ralf