Re: PA64 and libtool

[John David Anglin]

> If we do this, then the code in each libtool macro would look something
> like this
> 
> case $host_cpu
> ia64)
>   Do IA64 stuff
> hppa*64*)
>   Do 64bit stuff
> hppa2.0w)
>   Check for __LP64__ (for example)
>     Do 64bit
>   else
>     Do 32bit stuff
> hppa2.0 | hppa2.0n | hppa1.1 | hppa1.0 | *)
>   Do 32bit stuff
> esac
> 
> Personally I find this somewhat long winded and ugly.  I think I will
> submit a patch for libtool with

I agree.  We should have a consistent way of determinining when to
configure for the 64-bit environment.  At the moment, gcc and binutils
use hppa*64*.  They do not do a LP64 check when hppa2.0w is defined.
Libtool and other packages that need to do something special for the
64-bit environment should work the same way.

The configuration triplet affects the directories where things are
installed in some packages.  I think things will be clearer if we
avoid putting 64-bit stuff in ${prefix}/hppa2.0w-*-*.  Why add more
places to search and confusion as to where things will be installed?

It doesn't appear possible to build one version of libtool to handle
both 32 and 64-bit environments since different compilers and linkers
are needed, etc.

Thus, I would strongly prefer that hppa2.0w not be used for 64-bit
package configurations.

> just checks $host_cpu and anybody who wants to build for 64bit has to
> explicitly set --build.

As I noted in a previous email, the libtool testsuite runs configure
with a variety of different options.  However, the --build value used
in the initial configuaration of libtool is not passed to the testsuite,
so the testsuite runs in 32-mode using the 64-bit tools.  This is a
libtool bug.  However, a simple work-around is to have config.guess
automatically detect hppa64.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)