Re: Add hppa*64* support to libtool in binutils

Re: Add hppa*64* support to libtool in binutils

[ross.alexander]

David,

I'm currently looking at revising libtool-1.4e to add HPUX64 support.  I've
got a
couple of questions.

1) Should the mode be determined from $cpu_host or by checking __LP64__
in the cc defines.  Given that the config.guess returns
hppa2.0w-hp-hpux??.??
and we assume that is 32bit then do we assume the user knows what they
are doing and assume they only want 64bit when the target is hpux64.
Should
libtool check that they match correctly.

I'll use the values you used in your patch.  I assume these are pretty much
the default values for ELF environments.  Any hints would be appreciated.

Many thanks

Ross

---------------------------------------------------------------------------------

Ross Alexander                           "He knows no more about his
MIS - NEC Europe Limited            destiny than a tea leaf knows
Work ph: +44 20 8752 3394         the history of East India Company"

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

> I'm currently looking at revising libtool-1.4e to add HPUX64 support.  I've
> got a
> couple of questions.
> 
> 1) Should the mode be determined from $cpu_host or by checking __LP64__
> in the cc defines.  Given that the config.guess returns
> hppa2.0w-hp-hpux??.??

I believe that libtool should use hppa*64*-hp-hpux??.??.  That's what
gcc, binutils and other packages use.  I could see config.guess being
changed to return hppa*64* instead of hppa2.0w when CC defines __LP64__
and build=host.  When build=host and host is explicitly specified,
config.guess could check the consistency of the host triplet and
whether CC defines __LP64__.  However, in the general case, this
isn't possible.

Note that the match for the cpu part is hppa*64*.  Somebody thought
that additional characters might be added in the future both before
and after the "64".

> and we assume that is 32bit then do we assume the user knows what they
> are doing and assume they only want 64bit when the target is hpux64.

That's been the approach so far but I know many people initially find
it confusing.

> I'll use the values you used in your patch.  I assume these are pretty much
> the default values for ELF environments.  Any hints would be appreciated.

When the GNU linker is being used, the values are pretty much the default
values for ELF environments (except lt_cv_deplibs_check_method and
lt_cv_file_magic_test_file).  The HP linkers for ia64 and hppa64 appear
to be identical in their behavior, so the ia64 linker can be used as
a model.  I suspect that the dynamic loaders are also very similar
in functionality, although much is different at the binary level.  The
main difference as far as libtool goes is the library locations.

I first hacked away at libtool in libiconv-1.8 until this seemed to be
working and then used the changes as a model for what to do with libtool in
binutils/gcc.  Read the comments for each libtool define and compare with
manpage documentation for linker or dynamic loader.

I was going to submit a patch for the libtool source but haven't had a
chance to do this yet.  This is needed for the proper support of linking
shared libraries in many packages, so please go ahead with a patch.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Add hppa*64* support to libtool in binutils

[Jeff Law]

In message <OFA15CDC33.853DE7E3-ON80256C05.0038EA84@uk.neceur.com>, ross.alexan
der@uk.neceur.com writes:
 >
 >David,
 >
 >I'm currently looking at revising libtool-1.4e to add HPUX64 support.  I've
 >got a
 >couple of questions.
 >
 >1) Should the mode be determined from $cpu_host or by checking __LP64__
 >in the cc defines.  Given that the config.guess returns
 >hppa2.0w-hp-hpux??.??
 >and we assume that is 32bit then do we assume the user knows what they
 >are doing and assume they only want 64bit when the target is hpux64.
 >Should libtool check that they match correctly.
We certainly don't want to go into 64bit mode unless it's explicitly been
asked for.  If you can actually run the compiler, then checking for
__LP64__ should get you this information.  Alternately if you can't run
the compiler, go into 64bit mode for hppa64-*-* configurations only.  

jeff

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

> For those select few that do care about large address spaces, it's a 
> relatively small amount of work to either ask for them explicitly by
> the target name or by setting CC to an appropriate PA64 compiler before
> running configure.

Agreed.  I think that in most cases it is essential set CC, PATH, etc
to setup an appropriate 64-bit environment before configuring.  I would
like to make this as simple as possible.  For example, although it
doesn't seem technically necessary to the hardcode library paths (say
using the embedded path capability of the dynamic loader) in apps,
this might make it easier for users to run a mix of 32 and 64-bit apps.
This isn't absolutely needed since LD_LIBRARY_PATH can be used to
locate 64-bit libraries, but I think it is an option to consider.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Add hppa*64* support to libtool in binutils

[Jeff Law]

 In message <200208131836.g7DIaGFc028170@hiauly1.hia.nrc.ca>, "John David 
Anglin" writes:
 >That would be nice.  Looking at config.guess, I think it needs to do
 >a further check when HP_ARCH is found to be hppa2.0w using SC_CPU_VERSION
 >and SC_KERNEL_BITS.
Those would certainly be good sanity checks as they'll tell us if the
build machine is capable of running 64bit binaries.


 >Introducing the hppa64 arch wasn't a particularly great idea, but I don't
 >see any simple way around it.
Well, it beats having folks get PA64 tools by accident on machines which
support 64bit binaries; the vast majority of developers don't need or want
PA64 tools.

For those select few that do care about large address spaces, it's a 
relatively small amount of work to either ask for them explicitly by
the target name or by setting CC to an appropriate PA64 compiler before
running configure.

jeff

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]

Jeff Law wrote:

> In message <200208131637.g7DGbYKR027710@hiauly1.hia.nrc.ca>, "John David Anglin

>
>  >That would certainly seem convenient.  Also, libtool runs configure
>  >in its testsuite.  When I build it for hppa64, the testsuite unfortunately
>  >ignores the options used configuring it and as a result configures
>  >for hppa2.0w even though it is using 64bit tools  :-(
> Hmm, I hadn't thought of this case.  It probably makes sense though.
>
> ie, if I've done something like
>
> CC=<some PA64 compiler>
> configure
>
> Then, shouldn't that build a 64bit toolchain?  We have (in effect) explicitly
> asked for 64bit tools by the setting of CC.  It should probably also return
> hppa64-whatever as the "guessed" system.

I believe that the attached patch will do the trick.  Tested with a
couple of configurations of libtool in hppa2.0w-hp-hpux11.00 and
hppa64-hp-hpux11.00 modes.

Dave

[-- Attachment #2: config.guess.d --]
[-- Type: text/plain, Size: 804 bytes --]

2002-08-13  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* config.guess (9000/[34678]??:HP-UX:*:*): For 64-bit kernels, set
	HP_ARCH to hppa64 if the code level of CC_FOR_BUILD is 2.0w or 2.0W.

--- config.guess.orig	Mon Jan  7 17:09:42 2002
+++ config.guess	Tue Aug 13 15:20:07 2002
@@ -603,6 +603,20 @@
 		    rm -f $dummy.c $dummy
 		fi ;;
 	esac
+	if [ "${HP_ARCH}" = "hppa2.0w" ]; then
+	  # Check if the arch should be hppa2.0w or hppa64.
+	  eval $set_cc_for_build
+	  sed 's/^	//' << EOF >$dummy.c
+	int main () {}
+EOF
+	  (CCOPTS= $CC_FOR_BUILD $dummy.c -S) && HP_LEVEL=`awk '{if (NR==1) print $2}' $dummy.s`
+	  rm -f $dummy.c $dummy.s
+	  case ${HP_LEVEL} in
+	  2.0w | 2.0W)
+	    HP_ARCH=hppa64
+	    ;;
+	  esac
+	fi
 	echo ${HP_ARCH}-hp-hpux${HPUX_REV}
 	exit 0 ;;
     ia64:HP-UX:*:*)

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

> ie, if I've done something like
> 
> CC=<some PA64 compiler>
> configure

That would be nice.  Looking at config.guess, I think it needs to do
a further check when HP_ARCH is found to be hppa2.0w using SC_CPU_VERSION
and SC_KERNEL_BITS.

Introducing the hppa64 arch wasn't a particularly great idea, but I don't
see any simple way around it.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Add hppa*64* support to libtool in binutils

[Jeff Law]

In message <200208131637.g7DGbYKR027710@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 >> At the moment my is not to check in libtool itself for 64bit environment,
 >> and only use the $host_cpu variable as a guide to behaviour.  I have
 >> build gtk+-2.0.x with a patched libtool and it basically behaved itself,
 >> using the --build=hppa64-hp-hpux11.00 to tell libtool to expect 64bit code.
 >
 >I have a partial patch which I enclose below based on what I did to binutils
 >libtool.  I also have a couple of hacks for automake/autoconf.
 >
 >> A couple of questions.
 >> 
 >> 1) Do we put check in config.guess to output hppa64-hp-hpux11.xx if it
 >> detects a 64bit compiler (ie $CC -E | grep __LP64__ etc)?
 >
 >That would certainly seem convenient.  Also, libtool runs configure
 >in its testsuite.  When I build it for hppa64, the testsuite unfortunately
 >ignores the options used configuring it and as a result configures
 >for hppa2.0w even though it is using 64bit tools  :-(
Hmm, I hadn't thought of this case.  It probably makes sense though.

ie, if I've done something like

CC=<some PA64 compiler>
configure

Then, shouldn't that build a 64bit toolchain?  We have (in effect) explicitly
asked for 64bit tools by the setting of CC.  It should probably also return
hppa64-whatever as the "guessed" system.


Jeff

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

> At the moment my is not to check in libtool itself for 64bit environment,
> and only use the $host_cpu variable as a guide to behaviour.  I have
> build gtk+-2.0.x with a patched libtool and it basically behaved itself,
> using the --build=hppa64-hp-hpux11.00 to tell libtool to expect 64bit code.

I have a partial patch which I enclose below based on what I did to binutils
libtool.  I also have a couple of hacks for automake/autoconf.

> A couple of questions.
> 
> 1) Do we put check in config.guess to output hppa64-hp-hpux11.xx if it
> detects a 64bit compiler (ie $CC -E | grep __LP64__ etc)?

That would certainly seem convenient.  Also, libtool runs configure
in its testsuite.  When I build it for hppa64, the testsuite unfortunately
ignores the options used configuring it and as a result configures
for hppa2.0w even though it is using 64bit tools  :-(

> 2) Should hardcode_into_libs be true (true for SOM, false for IA64)?

Yes.  You can see the difference with chatr.  The SOM linker encodes
the full pathname of libraries in the library list.  Even if dynamic
searching is enabled, the dynamic loader will check the original
location for libraries.

The ELF linker for PA2.0W  (and IA64) doesn't do this.  It just puts the
basename of the library in the library list.  There is some question
in my mind about the definition of hardcode_minus_L.  I am pretty
sure the default is ok for PA2.0W and IA64.

> There is a bug in libtool-1.4e to do with rpath data polution deplibs, so I
> haven't produced a patch yet.

Isn't that only relevant when GNU ld is used?  I don't think we need
anything special in that case.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

--- libtool.m4.orig	Fri Aug  9 17:59:02 2002
+++ libtool.m4	Mon Aug 12 19:22:58 2002
@@ -1227,7 +1227,8 @@
   version_type=sunos
   need_lib_prefix=no
   need_version=no
-  if test "$host_cpu" = ia64; then
+  case $host_cpu in
+  ia64)
     hardcode_into_libs=yes
     dynamic_linker="$host_os dld.so"
     shlibpath_var=LD_LIBRARY_PATH
@@ -1240,13 +1241,25 @@
       sys_lib_search_path_spec="/usr/lib/hpux64 /usr/local/lib/hpux64"
     fi
     sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
-  else
+    ;;
+  hppa*64*)
+    hardcode_into_libs=yes
+    dynamic_linker="$host_os dld.sl"
+    shlibpath_var=LD_LIBRARY_PATH # Also SHLIB_PATH.
+    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
+    library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major $libname.sl'
+    soname_spec='${libname}${release}.sl$major'
+    sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
+    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+    ;;
+  *)
     dynamic_linker="$host_os dld.sl"
     shlibpath_var=SHLIB_PATH
     shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
     library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major $libname.sl'
     soname_spec='${libname}${release}.sl$major'
-  fi
+    ;;
+  esac
   # HP-UX runs *really* slowly unless shared libraries are mode 555.
   postinstall_cmds='chmod 555 $lib'
   ;;
@@ -1957,13 +1970,20 @@
 
 hpux10.20* | hpux11*)
   lt_cv_file_magic_cmd=/usr/bin/file
-  if test "$host_cpu" = ia64; then
+  case $host_cpu in
+  ia64)
     lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - IA64'
     lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
-  else
+    ;;
+  hppa*64*)
+    lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|ELF-[[0-9]][[0-9]]) shared object file - PA-RISC [[0-9]].[[0-9]]'
+    lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
+    ;;
+  *)
     lt_cv_deplibs_check_method='file_magic (s[[0-9]][[0-9]][[0-9]]|PA-RISC[[0-9]].[[0-9]]) shared library'
     lt_cv_file_magic_test_file=/usr/lib/libc.sl
-  fi
+    ;;
+  esac
   ;;
 
 irix5* | irix6* | nonstopux*)
@@ -2661,23 +2681,36 @@
     ;;
   hpux*)
     if test $with_gnu_ld = no; then
-      if test "$host_cpu" = ia64; then
+      case $host_cpu in
+      ia64 | hppa*64*)
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
-      else
+	;;
+      *)
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
 	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
-      fi
+	;;
+      esac
     fi
-    if test "$host_cpu" = ia64; then
+    case $host_cpu in
+    ia64)
       _LT_AC_TAGVAR(hardcode_direct, $1)=no
       _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-    else
+      _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
+					      # but as the default
+					      # location of the library.
+      ;;
+    hppa*64*)
+      _LT_AC_TAGVAR(hardcode_direct, $1)=no
+      _LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+      ;;
+    *)
       _LT_AC_TAGVAR(hardcode_direct, $1)=yes
-    fi
-    _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
-					    # but as the default
-					    # location of the library.
+      _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes # Not in the search PATH,
+					      # but as the default
+					      # location of the library.
+      ;;
+    esac
 
     case $cc_basename in
       CC)
@@ -2690,11 +2723,14 @@
 	  _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -b ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
 	  ;;
 	*)
-	  if test "$host_cpu" = ia64; then
+	  case $host_cpu in
+	  ia64 | hppa*64*)
 	    _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
-	  else
+	    ;;
+	  *)
 	    _LT_AC_TAGVAR(archive_cmds, $1)='$CC -b ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
-	  fi
+	    ;;
+	  esac
 	  ;;
 	esac
 	# Commands to make compiler produce verbose output that lists
@@ -2715,11 +2751,14 @@
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -shared -nostdlib -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
 	      ;;
 	    *)
-	      if test "$host_cpu" = ia64; then
+	      case $host_cpu in
+	      ia64 | hppa*64*)
 		_LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $linker_flags $libobjs $deplibs'
-	      else
+		;;
+	      *)
 		_LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $predep_objects $libobjs $deplibs $postdep_objects $compiler_flags'
-	      fi
+		;;
+	      esac
 	      ;;
 	    esac
 	  fi
@@ -3932,9 +3971,11 @@
   symcode='[[ABCDGISTW]]'
   ;;
 hpux*) # Its linker distinguishes data from code symbols
-  if test "$host_cpu" = ia64; then
+  case $host_cpu in
+  ia64 | hppa*64*)
     symcode='[[ABCDEGRST]]'
-  fi
+    ;;
+  esac
   lt_cv_sys_global_symbol_to_cdecl="sed -n -e 's/^T .* \(.*\)$/extern int \1();/p' -e 's/^$symcode* .* \(.*\)$/extern char \1;/p'"
   lt_cv_sys_global_symbol_to_c_name_address="sed -n -e 's/^: \([[^ ]]*\) $/  {\\\"\1\\\", (lt_ptr) 0},/p' -e 's/^$symcode* \([[^ ]]*\) \([[^ ]]*\)$/  {\"\2\", (lt_ptr) \&\2},/p'"
   ;;
@@ -4128,10 +4169,14 @@
       fi
       ;;
     hpux*)
-      # PIC is the default for IA64 HP-UX, but not for PA HP-UX.
-      if test "$host_cpu" != ia64; then
+      # PIC is the default for IA64 and PA2.0W HP-UX, but not for PA HP-UX.
+      case $host_cpu in
+      ia64 | hppa*64*)
+	;;
+      *)
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
-      fi
+	;;
+      esac
       ;;
     *)
       _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
@@ -4177,16 +4222,24 @@
 	  CC)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
-	    if test "$host_cpu" != ia64; then
+	    case host_cpu in
+	    ia64 | hppa*64*)
+	      ;;
+	    *)
 	      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
-	    fi
+	      ;;
+	    esac
 	    ;;
 	  aCC)
 	    _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
 	    _LT_AC_TAGVAR(lt_prog_compiler_static, $1)="${ac_cv_prog_cc_wl}-a ${ac_cv_prog_cc_wl}archive"
-	    if test "$host_cpu" != ia64; then
+	    case host_cpu in
+	    ia64 | hppa*64*)
+	      ;;
+	    *)
 	      _LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
-	    fi
+	      ;;
+	    esac
 	    ;;
 	  *)
 	    ;;
@@ -4370,10 +4423,14 @@
       ;;
 
     hpux*)
-      # PIC is the default for IA64 HP-UX, but not for PA HP-UX.
-      if test "$host_cpu" != ia64; then
+      # PIC is the default for IA64 and PA2.0W HP-UX, but not for PA HP-UX.
+      case $host_cpu in
+      ia64 | hppa*64*)
+	;;
+      *)
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='-fPIC'
-      fi
+	;;
+      esac
       ;;
 
     *)
@@ -4401,9 +4458,13 @@
 
     hpux9* | hpux10* | hpux11*)
       _LT_AC_TAGVAR(lt_prog_compiler_wl, $1)='-Wl,'
-      if test "$host_cpu" != ia64; then
+      case $host_cpu in
+      ia64 | hppa*64*)
+	;;
+      *)
 	_LT_AC_TAGVAR(lt_prog_compiler_pic, $1)='+Z'
-      fi
+	;;
+      esac
       # Is there a better lt_prog_compiler_static that works with the bundled CC?
       _LT_AC_TAGVAR(lt_prog_compiler_static, $1)='${wl}-a ${wl}archive'
       ;;
@@ -4996,11 +5057,14 @@
 	    _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$CC -shared -fPIC ${wl}+b ${wl}$install_libdir -o $output_objdir/$soname $libobjs $deplibs $compiler_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
 	    ;;
 	  *)
-	    if test "$host_cpu" = ia64; then
+	    case $host_cpu in
+	    ia64 | hppa*64*)
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}+h ${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
-	    else
+	      ;;
+	    *)
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$CC -shared -fPIC ${wl}+h ${wl}$soname ${wl}+b ${wl}$install_libdir -o $lib $libobjs $deplibs $compiler_flags'
-	    fi
+	      ;;
+	    esac
 	    ;;
 	esac
       else
@@ -5009,27 +5073,42 @@
 	    _LT_AC_TAGVAR(archive_cmds, $1)='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o $output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib'
 	    ;;
 	  *)
-	    if test "$host_cpu" = ia64; then
+	    case $host_cpu in
+	    ia64 | hppa*64*)
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
-	    else
+	      ;;
+	    *)
 	      _LT_AC_TAGVAR(archive_cmds, $1)='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags'
-	    fi
+	      ;;
+	    esac
 	    ;;
 	esac
       fi
-      if test "$host_cpu" = ia64; then
+      case $host_cpu in
+      ia64)
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
 	_LT_AC_TAGVAR(hardcode_direct, $1)=no
 	_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
-      else
+	# hardcode_minus_L: Not really in the search PATH,
+	# but as the default location of the library.
+	_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+	;;
+      hppa*64*)
+	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='-L$libdir'
+	_LT_AC_TAGVAR(hardcode_direct, $1)=no
+	_LT_AC_TAGVAR(hardcode_shlibpath_var, $1)=no
+	;;
+      *)
 	_LT_AC_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}+b ${wl}$libdir'
 	_LT_AC_TAGVAR(hardcode_libdir_separator, $1)=:
 	_LT_AC_TAGVAR(hardcode_direct, $1)=yes
-      fi
-      # hardcode_minus_L: Not really in the search PATH,
-      # but as the default location of the library.
-      _LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
-      _LT_AC_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.
+	_LT_AC_TAGVAR(hardcode_minus_L, $1)=yes
+	_LT_AC_TAGVAR(export_dynamic_flag_spec, $1)='${wl}-E'
+	;;
+      esac
       ;;
 
     irix5* | irix6* | nonstopux*)

Re: Add hppa*64* support to libtool in binutils

[ross.alexander]

Jeff,

At the moment my is not to check in libtool itself for 64bit environment,
and only use the $host_cpu variable as a guide to behaviour.  I have
build gtk+-2.0.x with a patched libtool and it basically behaved itself,
using the --build=hppa64-hp-hpux11.00 to tell libtool to expect 64bit code.

A couple of questions.

1) Do we put check in config.guess to output hppa64-hp-hpux11.xx if it
detects a 64bit compiler (ie $CC -E | grep __LP64__ etc)?

2) Should hardcode_into_libs be true (true for SOM, false for IA64)?

There is a bug in libtool-1.4e to do with rpath data polution deplibs, so I
haven't produced a patch yet.

Cheers,

Ross
---------------------------------------------------------------------------------

Ross Alexander                           "He knows no more about his
MIS - NEC Europe Limited            destiny than a tea leaf knows
Work ph: +44 20 8752 3394         the history of East India Company"


                                                                                                                                
                      Jeff Law                                                                                                  
                      <law@porcupine.slc.        To:       ross.alexander@uk.neceur.com                                         
                      redhat.com>                cc:       "John David Anglin" <dave@hiauly1.hia.nrc.ca>, aoliva@redhat.com,    
                                                  binutils@sources.redhat.com, binutils-owner@sources.redhat.com,               
                      12/08/2002 18:50            gcc-patches@gcc.gnu.org, sje@cup.hp.com, libtool@sources.redhat.com           
                      Please respond to          Subject:  Re: Add hppa*64* support to libtool in binutils                      
                      law                                                                                                       
                                                                                                                                
                                                                                                                                




In message <OFA15CDC33.853DE7E3-ON80256C05.0038EA84@uk.neceur.com>,
ross.alexan
der@uk.neceur.com writes:
 >
 >David,
 >
 >I'm currently looking at revising libtool-1.4e to add HPUX64 support.
I've
 >got a
 >couple of questions.
 >
 >1) Should the mode be determined from $cpu_host or by checking __LP64__
 >in the cc defines.  Given that the config.guess returns
 >hppa2.0w-hp-hpux??.??
 >and we assume that is 32bit then do we assume the user knows what they
 >are doing and assume they only want 64bit when the target is hpux64.
 >Should libtool check that they match correctly.
We certainly don't want to go into 64bit mode unless it's explicitly been
asked for.  If you can actually run the compiler, then checking for
__LP64__ should get you this information.  Alternately if you can't run
the compiler, go into 64bit mode for hppa64-*-* configurations only.

jeff

Re: Add hppa*64* support to libtool in binutils

[Loren James Rittle]

In article <200207151615.JAA16249@hpsje.cup.hp.com>,
Steve Ellcey<sje@cup.hp.com> writes:

>> This is a first cut at adding hppa64 support to libtool in binutils.
>> The same needs to done in gcc and in the libtool source.  Unfortunately,
>> the binutils and gcc sources are somewhat out of sync, so it seems
>> separate patches will be needed in each case.

> This would leave Loren Rittle's GCC libtool patch
> (http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00234.html) as the
> only difference between the binutils and GCC libtools.  Loren, do
> you know of any reason this patch couldn't be applied to the
> binutils libtool?

Hi Steve,

I have received no reports that the patch made the situation worse on
any platform.  Alex did report that it was not a complete solution to
the entire problem space and I concur with his analysis.  It has been
applied to libtool mainline.  Thus, I know of no reason why that patch
can't travel to the binutils copy of libtool.

Regards,
Loren

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

> > This is a first cut at adding hppa64 support to libtool in binutils.
> > The same needs to done in gcc and in the libtool source.  Unfortunately,
> > the binutils and gcc sources are somewhat out of sync, so it seems
> > separate patches will be needed in each case.
> 
> David, I verified that if my GCC libtool patch
> (http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00527.html) is applied to
> GCC then your binutils patch
> (http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00397.html) can be applied
> to GCC with out any changes.  I put both patches to my local tree
> (binutils and GCC) over the weekend and tested on PA32, PA64, and IA64
> HP-UX and had no problems.  This would leave Loren Rittle's GCC libtool

Thanks for for testing this.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Add hppa*64* support to libtool in binutils

[Steve Ellcey]

> This is a first cut at adding hppa64 support to libtool in binutils.
> The same needs to done in gcc and in the libtool source.  Unfortunately,
> the binutils and gcc sources are somewhat out of sync, so it seems
> separate patches will be needed in each case.

David, I verified that if my GCC libtool patch
(http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00527.html) is applied to
GCC then your binutils patch
(http://gcc.gnu.org/ml/gcc-patches/2002-07/msg00397.html) can be applied
to GCC with out any changes.  I put both patches to my local tree
(binutils and GCC) over the weekend and tested on PA32, PA64, and IA64
HP-UX and had no problems.  This would leave Loren Rittle's GCC libtool
patch (http://gcc.gnu.org/ml/gcc-patches/2002-05/msg00234.html) as the
only difference between the binutils and GCC libtools.  Loren, do you
know of any reason this patch couldn't be applied to the binutils
libtool?

I applied it to my binutils tree with no apparent bad effects.  It
probably isn't needed in binutils but it would keep the two versions of
libtool in synch.

Steve Ellcey
sje@cup.hp.com

Re: Add hppa*64* support to libtool in binutils

[John David Anglin]

> > There are some differences between the ia64 implementation and the
> > hppa64 proposed here.  The ia64 defines in ltcf-cxx.sh look suspect
> > to me.  It seems defines appropriate to the 32-bit SOM linker are
> > being used.
> 
> What defines look suspect to you?  It might just be that it is set up to
> use the HP linker and not the GNU linker.  The GNU linker has not been
> ported to the IA64 HP-UX platform.

This is the code:

  hpux*)
    if test $with_gnu_ld = no; then
      case "$host_cpu" in
	ia64*)
	  hardcode_libdir_flag_spec='-L$libdir'
	  hardcode_shlibpath_var=no ;;
	*)
	  hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir' ;;
      esac
      hardcode_direct=yes
      hardcode_libdir_separator=:
      export_dynamic_flag_spec='${wl}-E'
    fi
    hardcode_minus_L=yes # Not in the search PATH, but as the default
			 # location of the library.

I am pretty sure that hardcode_direct should be "no" for ia64 (see
ltcf-c.sh).  I believe that hardcode_libdir_separator and hardcode_minus_L
do not need to be defined if hardcode_direct is no.  I think
export_dynamic_flag_spec is ignored by the ia64 HP linker (it is by
64-bit hppa linker).  I also think we don't want hardcode_minus_L
with GNU ld.  So, I think a define for hardcode_direct should go
into the ia64 section of the case statement and the other four
should be in the default part.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

Re: Add hppa*64* support to libtool in binutils

[Steve Ellcey]

> There are some differences between the ia64 implementation and the
> hppa64 proposed here.  The ia64 defines in ltcf-cxx.sh look suspect
> to me.  It seems defines appropriate to the 32-bit SOM linker are
> being used.

What defines look suspect to you?  It might just be that it is set up to
use the HP linker and not the GNU linker.  The GNU linker has not been
ported to the IA64 HP-UX platform.

Steve Ellcey
sje@cup.hp.com

Add hppa*64* support to libtool in binutils

[John David Anglin]

This is a first cut at adding hppa64 support to libtool in binutils.
The same needs to done in gcc and in the libtool source.  Unfortunately,
the binutils and gcc sources are somewhat out of sync, so it seems
separate patches will be needed in each case.

Basically, it appears the capabilities of the ia64 and hppa64 linkers
are very similar.  The only differences appear to be the library
locations and the file magic needed for detecting shared libraries.

There are some differences between the ia64 implementation and the
hppa64 proposed here.  The ia64 defines in ltcf-cxx.sh look suspect
to me.  It seems defines appropriate to the 32-bit SOM linker are
being used.

I have revised sys_lib_search_path_spec and sys_lib_dlsearch_path_spec
for the 32-bit SOM linker.  I added /usr/ccs/lib and removed /usr/local/lib
from sys_lib_search_path_spec.  The is some question as to whether
we need /lib as it is normally a link to /usr/lib under hpux10 and 11.
I left it because I think it was a separate directory under hpux9.
The define for sys_lib_dlsearch_path_spec reflects the documented
behavior for dld.sl.

The hpux11 dynamic loader uses LD_LIBRARY_PATH, SHLIB_PATH and
the embedded patch in that order when searching dynamically for
shared libraries.  The code here sets shlibpath_var to LD_LIBRARY_PATH
for hppa*64*.  SHLIB_PATH isn't being checked but I was wondering
if there was a way to add this somehow.

I have tested this patch with several binutils builds under
hppa64-hp-hpux11.00 with --enable-shared shared.  I have built gcc
with the resulting tools.  The basic approach was derived from a
hack to libtool in the gettext package which involves building a
number of shared libraries with dependent libraries.  This testing
was done using the GNU linker.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)

2002-07-09  John David Anglin  <dave@hiauly1.hia.nrc.ca>

	* libtool.m4 (hpux10.20*|hpux11*): Add lt_cv_deplibs_check_method and
	lt_cv_file_magic_test_file defines for hppa*64*.
	* ltcf-c.sh (hpux9* | hpux10* | hpux11*): Add hardcode_direct,
	hardcode_shlibpath_var and hardcode_libdir_flag_spec defines for
	hppa*64*.
	* ltcf-cxx.sh (hpux*): Likewise.
	* ltcf-gcj.sh (hpux9* | hpux10* | hpux11*): Likewise.
	* ltconfig (hpux9* | hpux10* | hpux11*): Add dynamic_linker,
	shlibpath_var, shlibpath_overrides_runpath, library_names_spec,
	soname_spec, sys_lib_search_path_spec and sys_lib_dlsearch_path_spec
	for hppa*64*.  Update default values for sys_lib_search_path_spec and
	sys_lib_dlsearch_path_spec.

Index: libtool.m4
===================================================================
RCS file: /cvs/src/src/libtool.m4,v
retrieving revision 1.8
diff -u -3 -p -r1.8 libtool.m4
--- libtool.m4	28 Jan 2002 04:59:30 -0000	1.8
+++ libtool.m4	7 Jul 2002 18:16:03 -0000
@@ -584,15 +584,18 @@ gnu*)
   ;;
 
 hpux10.20*|hpux11*)
+  lt_cv_file_magic_cmd=/usr/bin/file
   case $host_cpu in
+  hppa*64*)
+    [lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - PA-RISC [0-9].[0-9]']
+    lt_cv_file_magic_test_file=/usr/lib/pa20_64/libc.sl
+    ;;
   hppa*)
     [lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library']
-    lt_cv_file_magic_cmd=/usr/bin/file
     lt_cv_file_magic_test_file=/usr/lib/libc.sl
     ;;
   ia64*)
     [lt_cv_deplibs_check_method='file_magic (s[0-9][0-9][0-9]|ELF-[0-9][0-9]) shared object file - IA64']
-    lt_cv_file_magic_cmd=/usr/bin/file
     lt_cv_file_magic_test_file=/usr/lib/hpux32/libc.so
     ;;
   esac
Index: ltcf-c.sh
===================================================================
RCS file: /cvs/src/src/ltcf-c.sh,v
retrieving revision 1.11
diff -u -3 -p -r1.11 ltcf-c.sh
--- ltcf-c.sh	28 Jan 2002 04:59:30 -0000	1.11
+++ ltcf-c.sh	7 Jul 2002 18:16:03 -0000
@@ -422,7 +422,8 @@ else
       hardcode_direct=no
       hardcode_shlibpath_var=no
       archive_cmds='$LD -b +h $soname -o $lib $libobjs $deplibs $linker_flags'
-      hardcode_libdir_flag_spec='-L$libdir' ;;
+      hardcode_libdir_flag_spec='-L$libdir'
+      ;;
     *)
       if test $with_gcc = yes; then
         case "$host_os" in
@@ -435,14 +436,23 @@ else
         *) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags' ;;
         esac
       fi
-      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
-      hardcode_libdir_separator=:
-      hardcode_minus_L=yes # Not in the search PATH, but as the default
-			   # location of the library.
+      case "$host_cpu" in
+      hppa*64*)
+	hardcode_direct=no
+	hardcode_shlibpath_var=no
+	hardcode_libdir_flag_spec='-L$libdir'
+	;;
+      *)
+	hardcode_direct=yes
+	hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+	hardcode_libdir_separator=:
+	hardcode_minus_L=yes # Not in the search PATH, but as the default
+			     # location of the library.
+	export_dynamic_flag_spec='${wl}-E'
+	;;
+      esac
       ;;
     esac
-    export_dynamic_flag_spec='${wl}-E'
-    hardcode_direct=yes
     ;;
 
   irix5* | irix6*)
Index: ltcf-cxx.sh
===================================================================
RCS file: /cvs/src/src/ltcf-cxx.sh,v
retrieving revision 1.13
diff -u -3 -p -r1.13 ltcf-cxx.sh
--- ltcf-cxx.sh	4 Jul 2002 22:51:16 -0000	1.13
+++ ltcf-cxx.sh	7 Jul 2002 18:16:03 -0000
@@ -252,17 +252,29 @@ case $host_os in
     if test $with_gnu_ld = no; then
       case "$host_cpu" in
 	ia64*)
+	  hardcode_direct=yes
 	  hardcode_libdir_flag_spec='-L$libdir'
-	  hardcode_shlibpath_var=no ;;
+	  hardcode_shlibpath_var=no
+	  hardcode_libdir_separator=:
+	  export_dynamic_flag_spec='${wl}-E'
+	  hardcode_minus_L=yes # Not in the search PATH, but as the default
+			       # location of the library.
+	  ;;
+	hppa*64*)
+	  hardcode_direct=no
+	  hardcode_libdir_flag_spec='-L$libdir'
+	  hardcode_shlibpath_var=no
+	  ;;
 	*)
-	  hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir' ;;
+	  hardcode_direct=yes
+	  hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+	  hardcode_libdir_separator=:
+	  export_dynamic_flag_spec='${wl}-E'
+	  hardcode_minus_L=yes # Not in the search PATH, but as the default
+			       # location of the library.
+	  ;;
       esac
-      hardcode_direct=yes
-      hardcode_libdir_separator=:
-      export_dynamic_flag_spec='${wl}-E'
     fi
-    hardcode_minus_L=yes # Not in the search PATH, but as the default
-			 # location of the library.
 
     case $cc_basename in
       CC)
Index: ltcf-gcj.sh
===================================================================
RCS file: /cvs/src/src/ltcf-gcj.sh,v
retrieving revision 1.8
diff -u -3 -p -r1.8 ltcf-gcj.sh
--- ltcf-gcj.sh	14 Nov 2001 06:24:41 -0000	1.8
+++ ltcf-gcj.sh	7 Jul 2002 18:16:03 -0000
@@ -414,12 +414,21 @@ else
     hpux9*) archive_cmds='$rm $output_objdir/$soname~$LD -b +b $install_libdir -o $output_objdir/$soname $libobjs $deplibs $linker_flags~test $output_objdir/$soname = $lib || mv $output_objdir/$soname $lib' ;;
     *) archive_cmds='$LD -b +h $soname +b $install_libdir -o $lib $libobjs $deplibs $linker_flags' ;;
     esac
-    hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
-    hardcode_libdir_separator=:
-    hardcode_direct=yes
-    hardcode_minus_L=yes # Not in the search PATH, but as the default
-			 # location of the library.
-    export_dynamic_flag_spec='${wl}-E'
+    case "$host_cpu" in
+    hppa*64*)
+      hardcode_direct=no
+      hardcode_shlibpath_var=no
+      hardcode_libdir_flag_spec='-L$libdir'
+      ;;
+    *)
+      hardcode_libdir_flag_spec='${wl}+b ${wl}$libdir'
+      hardcode_libdir_separator=:
+      hardcode_direct=yes
+      hardcode_minus_L=yes # Not in the search PATH, but as the default
+			   # location of the library.
+      export_dynamic_flag_spec='${wl}-E'
+      ;;
+    esac
     ;;
 
   irix5* | irix6*)
Index: ltconfig
===================================================================
RCS file: /cvs/src/src/ltconfig,v
retrieving revision 1.16
diff -u -3 -p -r1.16 ltconfig
--- ltconfig	28 Jan 2002 04:59:30 -0000	1.16
+++ ltconfig	7 Jul 2002 18:16:04 -0000
@@ -1173,12 +1173,23 @@ hpux9* | hpux10* | hpux11*)
     fi
     sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
     ;;
+  hppa*64*)
+    dynamic_linker="$host_os dld.sl"
+    shlibpath_var=LD_LIBRARY_PATH # How should we handle SHLIB_PATH?
+    shlibpath_overrides_runpath=yes # Unless +noenvvar is specified.
+    library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major $libname.sl'
+    soname_spec='${libname}${release}.sl$major'
+    sys_lib_search_path_spec="/usr/lib/pa20_64 /usr/ccs/lib/pa20_64"
+    sys_lib_dlsearch_path_spec=$sys_lib_search_path_spec
+    ;;
   *)
     dynamic_linker="$host_os dld.sl"
     shlibpath_var=SHLIB_PATH
     shlibpath_overrides_runpath=no # +s is required to enable SHLIB_PATH
     library_names_spec='${libname}${release}.sl$versuffix ${libname}${release}.sl$major $libname.sl'
     soname_spec='${libname}${release}.sl$major'
+    sys_lib_search_path_spec="/lib /usr/lib /usr/ccs/lib"
+    sys_lib_dlsearch_path_spec="/usr/lib /usr/ccs/lib"
     ;;
   esac
   # HP-UX runs *really* slowly unless shared libraries are mode 555.