This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Add hppa*64* support to libtool in binutils
- From: "John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>
- To: sje at cup dot hp dot com (Steve Ellcey)
- Cc: binutils at sources dot redhat dot com, gcc-patches at gcc dot gnu dot org
- Date: Wed, 10 Jul 2002 17:39:11 -0400 (EDT)
- Subject: Re: Add hppa*64* support to libtool in binutils
> > 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)