Re: DESTDIR install on hppa-hpux #3

[Michael Haubenwallner]

On Wed, 2009-06-24 at 11:25 +0200, Michael Haubenwallner wrote:
> On Wed, 2009-05-27 at 00:16 +0200, Michael Haubenwallner wrote:
> > Hi,
> > 
> > now I've managed to get 'make install DESTDIR=...' working on
> > hppa-hpux10 and hppa-hpux11 with libtool.
> 
> But wait, there's another subtlety: When the 'internal name' of a shared
> library does contain an absolute path instead of just a filename (or
> relative path), this absolute path is recorded as-is in the 'shared
> library list' as the fallback path into subsequent binaries.
> 
> I'm playing around with "+h $install_libdir/$soname", to come up with
> another patch to avoid the +cdp thing, which is a mess regarding cmdline
> length.

Ok, here's the third way of supporting DESTDIR on hppa-hpux, now without
the +cdp linker flag (#2), but using the absolute target libdir in the
'internal name' instead, to fix the security issue of #1.

        Fix DESTDIR install for hpux10 and hppa-hpux11 (32bit).
        * libltdl/m4/libtool.m4: Set hardcode_into_libs=yes, to allow
        for dlopening local uninstalled shared libraries even when they
        have the final target location encoded as fallback for dependant
        local shared libraries. Do not explicitly set runpath (+b linker
        flag) in archive_cmds, as this would defeat
        hardcode_into_libs=yes. Set hardcode_libdir_flag_spec_ld only
        when archive_cmds contains $LD, to get hardcode_into_libs
        working.
        Add check if gcc does work with nonexistent fallback locations
        for dependant shared libraries. If yes, prepend shared library's
        'internal name' with "$install_libdir/" to have the final target
        location stored into subsequent binaries as fallback instead of
        the linktime location. Also set hardcode_minus_L=no in this
        case, as it is not hardcoded when 'internal name' contains an
        absolute path.
        * tests/demo-hardcode.test: Try 'chatr' to read hardcoded paths,
        to detect 'static'-type dependant shared libraries, and to avoid
        false positives due to cc/aCC storing the cmdline into object
        files.

Do you think the change to use absolute path in 'internal name' should
be explicitly mentioned in doc/notes.texi?

This patch does have the same effect on test-results as before: 12 tests
changing from SKIP/XFAIL to PASS on hppa-hpux1[01] 32bit, no result
change for other tests/platforms.

Thank you!

/haubi/

libtool-hppa-hpux-abs-iname.patch
Description: Text Data