[PATCH] hppa64-hpux11: Add +nodefaultrpath option to archive_cmds
As on ia64, we need to add the +nodefaultrpath ld option when using the HP linker on hppa64. Without this option, we end up with the default rpath settings in the embedded search path. Often, this results in path references to build locations, particularly when libtool doesn't use the +b option to set the embedded path. Better late than never. Signed-off-by: Dave Anglin --- diff --git a/m4/libtool.m4 b/m4/libtool.m4 index f2d1f398..51ad2ae1 100644 --- a/m4/libtool.m4 +++ b/m4/libtool.m4 @@ -5718,7 +5718,7 @@ _LT_EOF if test yes,no = "$GCC,$with_gnu_ld"; then case $host_cpu in hppa*64*) - _LT_TAGVAR(archive_cmds, $1)='$CC -shared $wl+h $wl$soname -o $lib $libobjs $deplibs $compiler_flags' + _LT_TAGVAR(archive_cmds, $1)='$CC -shared $wl+h $wl$soname $wl+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags' ;; ia64*) _LT_TAGVAR(archive_cmds, $1)='$CC -shared $pic_flag $wl+h $wl$soname $wl+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags' @@ -5730,7 +5730,7 @@ _LT_EOF else case $host_cpu in hppa*64*) - _LT_TAGVAR(archive_cmds, $1)='$CC -b $wl+h $wl$soname -o $lib $libobjs $deplibs $compiler_flags' + _LT_TAGVAR(archive_cmds, $1)='$CC -b $wl+h $wl$soname $wl+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags' ;; ia64*) _LT_TAGVAR(archive_cmds, $1)='$CC -b $wl+h $wl$soname $wl+nodefaultrpath -o $lib $libobjs $deplibs $compiler_flags' @@ -6868,7 +6868,7 @@ if test yes != "$_lt_caught_CXX_error"; then aCC*) case $host_cpu in hppa*64*) - _LT_TAGVAR(archive_cmds, $1)='$CC -b $wl+h $wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags' + _LT_TAGVAR(archive_cmds, $1)='$CC -b $wl+h $wl$soname $wl+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags' ;; ia64*) _LT_TAGVAR(archive_cmds, $1)='$CC -b $wl+h $wl$soname $wl+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags' @@ -6892,7 +6892,7 @@ if test yes != "$_lt_caught_CXX_error"; then if test no = "$with_gnu_ld"; then case $host_cpu in hppa*64*) - _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC $wl+h $wl$soname -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags' + _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $wl+h $wl$soname $wl+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags' ;; ia64*) _LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $pic_flag $wl+h $wl$soname $wl+nodefaultrpath -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
Re: [PATCH] libtool -- don't print warnings with --silent
On 5-Sep-11, at 12:08 PM, Peter O'Gorman wrote: I pushed this patch on Saturday. Thanks. Dave, I've attached an approximation of what the patch would do to gcc's ltmain.sh and an addition to boehm-gc's .exp file. Both completely untested, of course :-) I'll give this patch a try in my next build. Your original patch worked. Dave
[PATCH] libtool -- don't print warnings with --silent
The attached patch fixes the boehm-gc testsuite on hppa2.0w-hp-hpux11.11.
Without it, libtool always generates an informational warning when linking
causing the entire boehm-gc testsuite to fail.
Ok? Ralf would you please install in libtool tree if ok.
2011-07-09 John David Anglin dave.ang...@nrc-cnrc.gc.ca
PR boehm-gc/48494
* ltmain.sh (func_warning): Don't print warnings if opt_silent is true.
Index: ltmain.sh
===
--- ltmain.sh (revision 176045)
+++ ltmain.sh (working copy)
@@ -437,7 +437,9 @@
# Echo program name prefixed warning message to standard error.
func_warning ()
{
-$opt_warning $ECHO $progname${mode+: }$mode: warning: ${1+$@} 12
+${opt_silent-false} || {
+ $opt_warning $ECHO $progname${mode+: }$mode: warning: ${1+$@} 12
+}
# bash bug again:
:
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)
On Sun, 19 Dec 2010, Ralf Wildenhues wrote: Sorry for the delay, I really would like to test the patch on the Libtool tree on a couple of systems, and write a Libtool testsuite addition for it, so we don't regress in the future. I hope to get to it before the end of the calendar year. If you'd like to help, you can download the Libtool source tree (git or nightly tarball from the website), apply the patch, run 'make -k check' and send the log files the output tells to send, on the HP systems you have available for testing. I installed git and the other tools needed to build the Libtool source. The file `tests/testsuite.log' was sent to bug-libt...@gnu.org yesterday. There was no difference in test results with and without the patch. The only significant fail that I see on hppa2.0w-hp-hpux11.11 is: 41: shlibpath_overrides_runpath FAILED (shlibpath.at:71) The failure of 115 appears to be caused by 41. If you come up with a testsuite addition, I can now easily test it. Dave
ping: [PATCH libtool] hardcoded path to dependent shared libraries on 32-bit hpux (libquadmath)
Ping. On Fri, 10 Dec 2010, John David Anglin wrote: On Sun, 28 Nov 2010, Ralf Wildenhues wrote: * John David Anglin wrote on Sun, Nov 28, 2010 at 09:42:43PM CET: The current relative path to libquadmath can be incorrectly interpreted on systems that hard code library paths. In particular, on 32-bit hppa*-*hpux*, the '..' part of the path is relative to the final executable. As a result, all libgfortran tests fail due to a dynamic loader error. The patch changes the path to an absolute path. Tested on hppa2.0w-hp-hpux11.11 and i686-apple-darwin9 with no observed regressions. OK for trunk? That doesn't seem to make sense to me. The fix should be in ltmain.sh or in libtool.m4. Please post the output of how libquadmath is linked on your system (the 'libtool --mode=link' command plus all of its output). The attached change to ltmain.sh fixes the above problem on on 32-bit hppa*-*hpux*. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Would you please apply if ok to libtool, gcc and sourceware? Thanks, Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) 2010-12-10 John David Anglin dave.ang...@nrc-cnrc.gc.ca * ltmain.sh (relink): Use absolute path when hardcoding with -L. Index: ltmain.sh === --- ltmain.sh (revision 167668) +++ ltmain.sh (working copy) @@ -5928,7 +5928,7 @@ test $hardcode_direct_absolute = no; then add=$dir/$linklib elif test $hardcode_minus_L = yes; then - add_dir=-L$dir + add_dir=-L$absdir # Try looking first in the location we're being installed to. if test -n $inst_prefix_dir; then case $libdir in Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: [patch libgfortran] path to libquadmath
On Sun, 28 Nov 2010, Ralf Wildenhues wrote: * John David Anglin wrote on Sun, Nov 28, 2010 at 09:42:43PM CET: The current relative path to libquadmath can be incorrectly interpreted on systems that hard code library paths. In particular, on 32-bit hppa*-*hpux*, the '..' part of the path is relative to the final executable. As a result, all libgfortran tests fail due to a dynamic loader error. The patch changes the path to an absolute path. Tested on hppa2.0w-hp-hpux11.11 and i686-apple-darwin9 with no observed regressions. OK for trunk? That doesn't seem to make sense to me. The fix should be in ltmain.sh or in libtool.m4. Please post the output of how libquadmath is linked on your system (the 'libtool --mode=link' command plus all of its output). The attached change to ltmain.sh fixes the above problem on on 32-bit hppa*-*hpux*. Tested on hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11. Would you please apply if ok to libtool, gcc and sourceware? Thanks, Dave -- J. David Anglin dave.ang...@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602) 2010-12-10 John David Anglin dave.ang...@nrc-cnrc.gc.ca * ltmain.sh (relink): Use absolute path when hardcoding with -L. Index: ltmain.sh === --- ltmain.sh (revision 167668) +++ ltmain.sh (working copy) @@ -5928,7 +5928,7 @@ test $hardcode_direct_absolute = no; then add=$dir/$linklib elif test $hardcode_minus_L = yes; then - add_dir=-L$dir + add_dir=-L$absdir # Try looking first in the location we're being installed to. if test -n $inst_prefix_dir; then case $libdir in
