Re: DESTDIR install on hppa-hpux #4
On Wed, 2009-07-01 at 16:04 +0200, Michael Haubenwallner wrote:
No problem. It's just that the hpux10.20 box is shot down tomorrow, so I
cannot test this platform any more.
The hpux10.20 box finally has been brought down now, and I have less
hope to get it up again even for testing only. This patch here was the
last one tested there.
* Michael Haubenwallner wrote on Mon, Jun 29, 2009 at 11:22:31AM CEST:
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.
Using absolute paths seems like a step backward, with all the world
wanting relocatable packages more than anything. I don't think we
should go that way unless we cannot help it at all. But maybe I have
misunderstood you latest approach?
Do you mean subsequent linked binaries should not contain the location
the dependent shared library was originally targetted for?
Well, I can agree here. Patch#2 with the +cdp mess would avoid that.
For completion: The +cdp mess means that for each required local
shared library the linkline gets bloated by
+cdp $inst_prefix_dir$install_libdir/$soname:$install_libdir/$soname
Here's the fourth try:
The uninstalled shared libraries get absolute $install_libdir/$soname
into the internal name, to be able to create the local executables for
fast_install, without any embedded $builddir or $inst_prefix_dir, and
without the +cdp mess.
But this needs to force each local shared library - even those without
local dependencies - to be relinked for installation. Relinking is done
with $soname only as internal name, requiring +cdp $inst_prefix_dir:
only once to avoid inst_prefix_dir in the fallback path.
The runpath is again hardcoded into shared libraries too.
IMHO the basic problem here is that for binaries there is nothing known
like $install_bindir, similar to $install_libdir for libraries.
Same 12 tests change from SKIP/XFAIL to PASS as before, without any
other test result change.
Another question:
HP-UX does support SHLIB_PATH for 32bit hppa, and both LD_LIBRARY_PATH
and SHLIB_PATH for hppa64 and ia64 (32/64), which can be enabled easily.
This would require the +s linker flag for executables too, but I haven't
found a way to do this. Thoughts?
Thanks!
/haubi/
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1fe09d2..1727070 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2332,6 +2332,10 @@ hpux9* | hpux10* | hpux11*)
shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
+case $host_os in
+hpux9*) ;;
+*) hardcode_into_libs=yes ;;
+esac
;;
esac
# HP-UX runs *really* slowly unless shared libraries are mode 555, ...
@@ -4760,25 +4764,59 @@ _LT_EOF
;;
hpux10*)
+ # gcc-3.0.1 does some post-link processing which breaks when the
+ # just created binary has a nonexistent 'dynamic dependency'.
+ AC_CACHE_CHECK([whether absolute path of internal name works with $CC],
+ [_LT_TAGVAR(lt_cv_cdp_works, $1)],
+ [_LT_TAGVAR(lt_cv_cdp_works, $1)=:
+ if test $GCC = yes; then
+ save_LDFLAGS=$LDFLAGS
+ LDFLAGS=$LDFLAGS -Wl,+cdp -Wl,/usr/lib:/nonexistent -Wl,+cdp -Wl,/lib:/nonexistent
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+ [], [_LT_TAGVAR(lt_cv_cdp_works, $1)=false])
+ LDFLAGS=$save_LDFLAGS
+ fi
+ ])
if test $GCC = yes test $with_gnu_ld = no; then
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ $_LT_TAGVAR(lt_cv_cdp_works, $1)
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC`test $mode = relink func_echo_all ${wl}+cdp ${wl}$inst_prefix_dir: ${wl}+h ${wl} || func_echo_all ${wl}+h ${wl}$install_libdir/`$soname -o $lib $libobjs $deplibs $compiler_flags~need_relink=yes' ||
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
else
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ $_LT_TAGVAR(lt_cv_cdp_works, $1)
+ _LT_TAGVAR(archive_cmds, $1)='$LD -b`test $mode = relink func_echo_all +cdp $inst_prefix_dir: +h || func_echo_all +h $install_libdir/`$soname -o $lib $libobjs $deplibs $linker_flags~need_relink=yes' ||
+ _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
+ _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
fi
if test $with_gnu_ld = no; then
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
Re: DESTDIR install on hppa-hpux #3
On Tue, 2009-06-30 at 20:35 +0200, Ralf Wildenhues wrote: Hello Michael, I'm pretty short on review time ATM; sorry for not providing a detailed review. No problem. It's just that the hpux10.20 box is shot down tomorrow, so I cannot test this platform any more. * Michael Haubenwallner wrote on Mon, Jun 29, 2009 at 11:22:31AM CEST: 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. Using absolute paths seems like a step backward, with all the world wanting relocatable packages more than anything. I don't think we should go that way unless we cannot help it at all. But maybe I have misunderstood you latest approach? Do you mean subsequent linked binaries should not contain the location the dependent shared library was originally targetted for? Well, I can agree here. Patch#2 with the +cdp mess would avoid that. But another try: It should work to *link* the shared libraries *with* the absolute internal name, so in-package executables get this as fallback path without the +cdp mess, and to *relink* the shared libraries *without* the absolute internal name, but using the +cdp linker flag once to drop the $inst_prefix_dir. Another question: HP-UX does support SHLIB_PATH for 32bit hppa, and both LD_LIBRARY_PATH and SHLIB_PATH for hppa64 and ia64 (32/64), which can be enabled easily. Is it preferred to use the runpath from an environment variable? Thanks! /haubi/
Re: DESTDIR install on hppa-hpux #3
Hello Michael, I'm pretty short on review time ATM; sorry for not providing a detailed review. * Michael Haubenwallner wrote on Mon, Jun 29, 2009 at 11:22:31AM CEST: 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. Using absolute paths seems like a step backward, with all the world wanting relocatable packages more than anything. I don't think we should go that way unless we cannot help it at all. But maybe I have misunderstood you latest approach? Thanks, Ralf
Re: DESTDIR install on hppa-hpux #3
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/
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 1fe09d2..dba121e 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -2332,6 +2332,10 @@ hpux9* | hpux10* | hpux11*)
shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${release}${shared_ext}$major $libname${shared_ext}'
soname_spec='${libname}${release}${shared_ext}$major'
+case $host_os in
+hpux9*) ;;
+*) hardcode_into_libs=yes ;;
+esac
;;
esac
# HP-UX runs *really* slowly unless shared libraries are mode 555, ...
@@ -4760,25 +4764,64 @@ _LT_EOF
;;
hpux10*)
+ # gcc-3.0.1 does some post-link processing which breaks when the
+ # just created binary has a nonexistent 'dynamic dependency'.
+ AC_CACHE_CHECK([for absolute path of internal name with $CC],
+ [_LT_TAGVAR(lt_cv_abspath_internal_name, $1)],
+ [_LT_TAGVAR(lt_cv_abspath_internal_name, $1)=
+ if test $GCC = yes; then
+ save_LDFLAGS=$LDFLAGS
+ LDFLAGS=$LDFLAGS -Wl,+cdp -Wl,/usr/lib:/nonexistent -Wl,+cdp -Wl,/lib:/nonexistent
+ AC_LINK_IFELSE([AC_LANG_PROGRAM([],[])],
+ [_LT_TAGVAR(lt_cv_abspath_internal_name, $1)='$install_libdir/'],
+ [_LT_TAGVAR(lt_cv_abspath_internal_name, $1)=])
+ LDFLAGS=$save_LDFLAGS
+ else
+ _LT_TAGVAR(lt_cv_abspath_internal_name, $1)='$install_libdir/'
+ fi
+ ])
if test $GCC = yes test $with_gnu_ld = no; then
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}'[$]_LT_TAGVAR(lt_cv_abspath_internal_name, $1)'$soname -o $lib $libobjs $deplibs $compiler_flags'
else
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$LD -b +h '[$]_LT_TAGVAR(lt_cv_abspath_internal_name, $1)'$soname -o $lib $libobjs $deplibs $linker_flags'
+ _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
fi
if test $with_gnu_ld = no; then
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_TAGVAR(hardcode_direct, $1)=yes
_LT_TAGVAR(hardcode_direct_absolute, $1)=yes
_LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
# hardcode_minus_L: Not really in the search PATH,
- # but as the default location of the library.
-
Re: DESTDIR install on hppa-hpux
Hi Ralf,
On Fri, 2009-06-12 at 21:57 +0200, Michael Haubenwallner wrote:
Hmm. This does open a small security issue, no?
That's precisely the reason we haven't gone this way
before.
Asking HP people (or more carefully reading the manpage) does help: The
linker does have the +cdp flag, which allows for changing the linktime
path of a library into something different being stored as fallback path
into the binary. It does even work on hpux10.20 (ld B.10.37 here)
although not mentioned in its manpage.
Here's a patch that uses the +cdp linker flag to close the security
issue with the fallback path encoded into the SOM binaries, by adding
another libtool property 'fix_hardcoded_libdir_flag_spec', only used for
hppa-hpux (32bit). It is configure-checked if compiler/linker do support
this flag.
This allows for hardcode_action=immediate and fast_install=yes, required
for DESTDIR support.
tests/deplibs-ident.at has to filter this flag, as it would lead to
false positives.
The same 12 tests as before are turned from SKIP/XFAIL to PASS on all
the setups as before, with one exception: It is collect2 of gcc-3.0.1 on
hppa-hpux10 here, which erroneously interprets -Wl,+cdp and fails to
find libraries. So no tests do change their result in this setup.
Thank you!
/haubi/
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 6f44d35..f7d098d 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3801,6 +3801,8 @@ func_mode_link ()
lib_search_path=`pwd`
inst_prefix_dir=
new_inherited_linker_flags=
+fix_hardcoded_libdir_flag=
+fix_hardcoded_libdir_flag_ld=
avoid_version=no
dlfiles=
@@ -5436,6 +5438,15 @@ func_mode_link ()
elif test $hardcode_shlibpath_var = no; then
add_shlibpath=$dir
add=-l$name
+ elif test -n $fix_hardcoded_libdir_flag_spec; then
+ add_dir=-L${absdir}
+ add=-l$name
+ if test ${linkmode} = prog test X${absdir} != X${libdir}; then
+ linkdir=$absdir
+ eval fix_hardcoded_libdir_flag=\\${fix_hardcoded_libdir_flag} ${fix_hardcoded_libdir_flag_spec}\
+ # fix_hardcoded_libdir_flag_ld not needed, programs are linked with $CC
+ $lt_unset linkdir
+ fi
else
lib_linked=no
fi
@@ -5503,6 +5514,15 @@ func_mode_link ()
elif test $hardcode_minus_L = yes; then
add_dir=-L$libdir
add=-l$name
+ if test -n $inst_prefix_dir
+ test -f $inst_prefix_dir$libdir/$linklib
+ test -n ${fix_hardcoded_libdir_flag_spec}; then
+ linkdir=$inst_prefix_dir$libdir
+ add_dir=-L$linkdir
+ eval fix_hardcoded_libdir_flag=\\${fix_hardcoded_libdir_flag} ${fix_hardcoded_libdir_flag_spec}\
+ eval fix_hardcoded_libdir_flag_ld=\\${fix_hardcoded_libdir_flag_ld} ${fix_hardcoded_libdir_flag_spec_ld}\
+ $lt_unset linkdir
+ fi
elif test $hardcode_shlibpath_var = yes; then
case :$finalize_shlibpath: in
*:$libdir:*) ;;
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 5f24fab..9907f66 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1905,6 +1905,7 @@ if test -n $_LT_TAGVAR(hardcode_libdir_flag_spec, $1) ||
# have to relink, otherwise we might link with an installed library
# when we should be linking with a yet-to-be-installed one
## test $_LT_TAGVAR(hardcode_shlibpath_var, $1) != no
+ test -z $_LT_TAGVAR(fix_hardcoded_libdir_flag_spec, $1)
test $_LT_TAGVAR(hardcode_minus_L, $1) != no; then
# Linking always hardcodes the temporary library directory.
_LT_TAGVAR(hardcode_action, $1)=relink
@@ -4175,6 +4176,8 @@ m4_if([$1], [CXX], [
_LT_TAGVAR(hardcode_libdir_separator, $1)=
_LT_TAGVAR(hardcode_minus_L, $1)=no
_LT_TAGVAR(hardcode_shlibpath_var, $1)=unsupported
+ _LT_TAGVAR(fix_hardcoded_libdir_flag_spec, $1)=
+ _LT_TAGVAR(fix_hardcoded_libdir_flag_spec_ld, $1)=
_LT_TAGVAR(inherit_rpath, $1)=no
_LT_TAGVAR(link_all_deplibs, $1)=unknown
_LT_TAGVAR(module_cmds, $1)=
@@ -4758,13 +4761,12 @@ _LT_EOF
hpux10*)
if test $GCC = yes test $with_gnu_ld = no; then
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags $fix_hardcoded_libdir_flag'
else
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags $fix_hardcoded_libdir_flag_ld'
fi
if test $with_gnu_ld = no; then
- _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
+ _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir $fix_hardcoded_libdir_flag'
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
_LT_TAGVAR(hardcode_direct, $1)=yes
Re: DESTDIR install on hppa-hpux
On Sun, 2009-06-14 at 16:21 +0200, Ralf Wildenhues wrote:
+ Set hardcode_libdir_flag_spec_ld along direct use of $LD only (hpux10).
... this line is problematic, because ...
Hmm, ...
@@ -4713,20 +4716,20 @@ _LT_EOF
hpux10*)
if test $GCC = yes test $with_gnu_ld = no; then
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o
$lib $libobjs $deplibs $compiler_flags'
else
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o
$lib $libobjs $deplibs $linker_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'
+ _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
fi
if test $with_gnu_ld = no; then
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
... this removed line ...
... this is 'hpux10*', ...
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -4757,9 +4760,9 @@ _LT_EOF
# (HP92453-01 A.11.01.20 doesn't, HP92453-01 B.11.X.35175-35176.GP
does)
_LT_LINKER_OPTION([if $CC understands -b],
_LT_TAGVAR(lt_cv_prog_compiler__b, $1), [-b],
- [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'],
- [_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'])],
- [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'])
+ [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'],
+ [_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'])],
... is also used for this older 11.00 compiler version (which you
probably don't have on your systems).
... while this is 'hpux11*', so how can this happen?
Anyway, maybe the usage of $hardcode_libdir_flag_spec_ld in ltmain.m4sh
is problematic instead, as it is unconditionally used if set, even when
$CC (but not $LD) is in $archive_cmds:
6652 if test -n $hardcode_libdir_flag_spec_ld; then
6653 eval dep_rpath=\$hardcode_libdir_flag_spec_ld\
6654 else
6655 eval dep_rpath=\$hardcode_libdir_flag_spec\
6656 fi
$CC might not understand +b directly, which was why I moved setting
hardcode_libdir_flag_spec_ld up to where archive_cmds is set to '$LD',
to not have it set when archive_cmds is '$CC'.
Thanks!
/haubi/
Re: DESTDIR install on hppa-hpux
Hello Michael,
digging slowly through the issues. In this patch, ...
* Michael Haubenwallner wrote on Wed, May 27, 2009 at 12:16:59AM CEST:
+ Fix DESTDIR install for hppa-hpux10 and hppa-hpux11.
+ * libltdl/m4/libtool.m4: Set hardcode_into_libs=yes.
+ Set hardcode_minus_L back to 'no', as the stored path only is used as
+ fallback when the library is not found via runpath.
+ Do not set runpath with +b $install_libdir, as this would ignore the
+ collected runpath subsequently set with +b $libdir.
+ Set hardcode_libdir_flag_spec_ld along direct use of $LD only (hpux10).
... this line is problematic, because ...
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -4713,20 +4716,20 @@ _LT_EOF
hpux10*)
if test $GCC = yes test $with_gnu_ld = no; then
- _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname
${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname -o
$lib $libobjs $deplibs $compiler_flags'
else
- _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o
$lib $libobjs $deplibs $linker_flags'
+ _LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'
+ _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
fi
if test $with_gnu_ld = no; then
_LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
- _LT_TAGVAR(hardcode_libdir_flag_spec_ld, $1)='+b $libdir'
... this removed line ...
_LT_TAGVAR(hardcode_libdir_separator, $1)=:
@@ -4757,9 +4760,9 @@ _LT_EOF
# (HP92453-01 A.11.01.20 doesn't, HP92453-01 B.11.X.35175-35176.GP
does)
_LT_LINKER_OPTION([if $CC understands -b],
_LT_TAGVAR(lt_cv_prog_compiler__b, $1), [-b],
- [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'],
- [_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir
-o $lib $libobjs $deplibs $linker_flags'])],
- [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b
${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'])
+ [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'],
+ [_LT_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs
$deplibs $linker_flags'])],
... is also used for this older 11.00 compiler version (which you
probably don't have on your systems).
+ [_LT_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname -o $lib
$libobjs $deplibs $compiler_flags'])
Cheers,
Ralf
Re: DESTDIR install on hppa-hpux
On Thu, 2009-06-04 at 23:45 +0200, Ralf Wildenhues wrote:
* 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.
Asking HP people (or more carefully reading the manpage) does help: The
linker does have the +cdp flag, which allows for changing the linktime
path of a library into something different being stored as fallback path
into the binary. It does even work on hpux10.20 (ld B.10.37 here)
although not mentioned in its manpage.
It should be enough to simply add +cdp ${inst_prefix_dir}: to each
relink line, to replace ${inst_prefix_dir} with .
But I still have to look how to integrate this into libtool - any help
appreciated.
Thanks!
/haubi/
Re: DESTDIR install on hppa-hpux
On Thu, 2009-06-04 at 23:45 +0200, Ralf Wildenhues wrote: * 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. Ah, I see. Hmm, I'll have to keep a patch myself then, as using DESTDIR is a blocker here... So the 'chatr' hunk in the test also must not ignore the fallback path then. But it still helps for cc/aCC, as they both encode the commandline into each object file leading to false positives otherways. 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? Hmm, could be indeed. The 'chatr' part definitively is independent too, although with above mentioned change. Thanks! /haubi/
Re: DESTDIR install on hppa-hpux
* 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
Re: DESTDIR install on hppa-hpux
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/
Re: DESTDIR install on hppa-hpux
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 64HP C Compiler PHCO_27774 + HP ANSI C++ A.03.52 ia64 11.23 32gcc-4.2.4 ia64 11.23 32HP aC++/ANSI C A.06.10 (both cc/aCC) ia64 11.23 64gcc-4.2.4 ia64 11.23 64HP 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 64HP 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
