This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
PA64 configure issues
- To: gcc at gcc dot gnu dot org, gdb at sourceware dot cygnus dot com, binutils at sourceware dot cygnus dot com, autoconf at sourceware dot cygus dot com
- Subject: PA64 configure issues
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 25 Apr 2000 10:23:42 -0600
- Reply-To: law at cygnus dot com
I have an issue that affects a variety of projects that we need to hash
through.
Newer HP machines have the capability of running both 32bit (PA32) and
64bit (PA64) binaries.
PA32 and PA64 are radically different in a number of ways which make
supporting both with a single toolchain very difficult/impossible.
In general, most developers do not need PA64 capabilities, in fact, using
PA64 generally results in programs that are larger and slower than PA32
programs. My current thoughts are to have the GNU tools default to PA32
and require special options or configure names to enable PA64 capabilities.
Right now on a PA64 capable machine config.guess will return something like
hppa2.0w-hp-hpux11.00
^
+------ This indicates the machine has the capability to run PA64
code.
One idea is to have config.guess never indicate if the machine is PA64
capable. ie, in the above example config.guess would return
hppa2.0-hp-hpux11.00
That would allow all the existing configury bits to default to PA32 and
the user could expicitly ask for PA64 by using the target triplet with the
"w" indicator.
Other option would be to make the 64bit tools have a triplet like
hppa64-hp-hpux11.00 or something like that. It wouldn't require any
changes to config.guess to get the desired behavior.
I'm willing to do either (or anything else that sounds reasonable). The only
trick is we have to do something that is consistent across gcc, binutils, gdb
and autoconf.
jeff