Re: 64bit HPUX problems

[Jeff Law]

 In message <address@hidden>, "John David 
Anglin" writes:
 >> 'hppa2.0w' represents the architecture. It has nothing to do with
 >> HP-UX.
Almost true.

The "w" is unfortunately actually related to the OS, not the architecture.

You can easily get a machine from HP which contains a fully functional
PA2.0 processor, but where the OS will not run 64bit binaries.  For those
machines config.guess will give you "hppa2.0" (or hppa2.0n).

config.guess will only return "hppa2.0w" if the OS is capable of running
64bit binaries.

Yes, in retrospect, that little nugget of information should have been
encoded in the OS field, not the architecture field.


 >Now, the check of __LP64__ is really a check of the data model
 >being used by the compiler.  While __LP64__ is currently equivalent
 >to the +DA2.0W architecute (HP cc nomenclature) and the ILP32 model
 >is equivalent to the +DA1.1 architecture, there is no guarantee
 >that this will always be the case.  It would probably be better
 >to check the value of the .LEVEL directive in some assembler
 >output if you want to determine the architecture being used
 >by the compiler.
No, don't check .level.  __LP64__ states very explicitly that we're going
to be using the 64bit data model, which is precisely what hppa64 is for.

 >Won't work.  Gcc and binutils do not allow selecting 32-bit or 64-bit
 >output with a flag.  You need separate tools, runtime libraries, etc.
 >Jeff probably has a better idea how much work is involved in integrating
 >the tools but I don't think it will happen in the next year.
Oh man.  It's unpleasant at best and not worth the effort.

Unlike other systems which have 32bit and 64bit capabilities, HP's use
completely different object file formats, radically different calling
conventions depending on whether you're building 32bit or 64bit tools.
Trying to build a GNU toolchain which can handle both simply isn't worth
the effort.

FWIW, HP didn't even do this -- all the programs in their toolchain (compiler,
linker, assembler, binutils equivalents) are actually just front-ends which
parse the switches and run different copies of the programs depending on if
you're building 32bit stuff or 64bit stuff.  That's why you see two copies
of every program in /usr/ccs/lbin.

jeff