Re: PA64 configure issues

Re: PA64 configure issues

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

On Apr 27, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>   In message < or4s8pdhue.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
>> On Apr 25, 2000, Jeffrey A Law <law@cygnus.com> wrote:

>> I like the idea of matching hppa*64-*-hpux* to select 64bit support.

> My only concern is configure scripts that aren't using wildcards
> correctly, but I guess we'll find those soon enough :-)

I think the most common case of match hppa*-*-hpux* will still work
for most applications, since it probably would not make that much
difference.  And, since presumably you'll take care of the tool-chain,
you'll have taken care of the most likely spots.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: PA64 configure issues

[Jeffrey A Law]

  In message < or7ldja0h7.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
> I think the most common case of match hppa*-*-hpux* will still work
  > for most applications, since it probably would not make that much
  > difference.  And, since presumably you'll take care of the tool-chain,
  > you'll have taken care of the most likely spots.
I'm not worried about the ones with hppa* -- I've already identified those;
it's those which do stuff like hppa?.? that I worry about.

jeff

Re: PA64 configure issues

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Apr 27, 2000, Jeffrey A Law <law@cygnus.com> wrote:

> I'm not worried about the ones with hppa* -- I've already identified those;
> it's those which do stuff like hppa?.? that I worry about.

Well, those are already broken, since this doesn't match hppa-*-hpux*.
And they don't match the trailing `w' either, so it's ok if they don't
match an additional trailing `64'.  I wouldn't worry about them.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: PA64 configure issues

[Jeffrey A Law]

  In message < orpurb8k6p.fsf@zecarneiro.lsd.ic.unicamp.br >you write:
  > On Apr 27, 2000, Jeffrey A Law <law@cygnus.com> wrote:
  > 
  > > I'm not worried about the ones with hppa* -- I've already identified thos
  > e;
  > > it's those which do stuff like hppa?.? that I worry about.
  > 
  > Well, those are already broken, since this doesn't match hppa-*-hpux*.
  > And they don't match the trailing `w' either, so it's ok if they don't
  > match an additional trailing `64'.  I wouldn't worry about them.
hppa without a version number is not valid in a configuration string.  The
fact that gcc and maybe other accept it is lame and broken.

jeff

Re: PA64 configure issues

[Alexandre Oliva]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 613 bytes --]

On Apr 25, 2000, Jeffrey A Law <law@cygnus.com> wrote:

> 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 like the idea of matching hppa*64-*-hpux* to select 64bit support.

-- 
Alexandre Oliva    Enjoy Guaraná, see http://www.ic.unicamp.br/~oliva/
Cygnus Solutions, a Red Hat company        aoliva@{redhat, cygnus}.com
Free Software Developer and Evangelist    CS PhD student at IC-Unicamp
oliva@{lsd.ic.unicamp.br, gnu.org}   Write to mailing lists, not to me

Re: PA64 configure issues

[Jeffrey A Law]

  In message < 200004251814.OAA28140@mal-ach.watson.ibm.com >you write:
  > 	Geoff gave the background on 64-bit AIX support which can support
  > both modes with a single toolchain, defaulting to 32-bit mode.  This also
  > happens to be the way that the AIX product compilers operate, so the two
  > are consistent.
Good.

  > 	The above line in your original message jumps out at me.  Are you
  > saying that you must build an entirely separate compiler for PA64?  Also,
  > you did not mention how HP's commercial toolchain operates/defaults.
Yes, we have to build a separate toolchain.  Among other things PA32 and PA64
use completely different object file formats (SOM & ELF respectively) one
supports gnu-ld (PA64) the other will never support gnu-ld (PA32).  There's
other issues, but those are the two biggest.

HP's tools work by having a front-end which invisibly fires up the appropriate
32bit or 64bit tool based on runtime flags.  

  > 	I would agree that defaulting to 32-bit mode, even on 64-bit
  > hardware, is the best choice when the hardware can support both modes. 
OK.

  > If
  > the user needs to configure and build a completely separate toolchain for
  > 64-bit mode, that is much more cumbersome than the AIX toolchain.
Yup.  And that's the root of the problem I'm trying to resolve.

  > If HP's
  > toolchain defaults differently, I think that you need to consider
  > user-interface compatibility as well.
I don't think we're going to have that kind of compatibility.  At least not
at this stage.


jeff