This is the mail archive of the
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: ross dot alexander at uk dot neceur dot com
- Cc: aoliva at redhat dot com, binutils at sources dot redhat dot com, binutils-owner at sources dot redhat dot com, gcc-patches at gcc dot gnu dot org, sje at cup dot hp dot com, libtool at sources dot redhat dot com
- Date: Mon, 29 Jul 2002 11:16:09 -0400 (EDT)
- Subject: Re: Add hppa*64* support to libtool in binutils
> 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
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
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
> 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.
J. David Anglin email@example.com
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)