On Thu, 2008-05-15 at 12:32 +0200, Fabian Groffen wrote:
> On 15-05-2008 11:58:50 +0200, Michael Haubenwallner wrote:
> > Hi,
> > 
> > While 'ia64-hpux' is a multilib platform, and the compilers (HP-cc, gcc)
> > support this, their default output still is 32bit.
> > 
> > This is the reason why currently the 'ia64-hpux' keyword in prefix
> > stands for 32bit, but IMO this is just wrong.
> 
> Feels really wrong indeed.  They just do like any other UNIX does, but
> on a 64-bits chip.

Hmm, can't understand the "but" here: don't we have this problem for any
multilib-capable Unix too (you hacked sth. for Solaris already) ?

Fex config.guess does not know "powerpc64-ibm-aix*" on a 64bit
AIX-kernel, it's still "powerpc-ibm-aix*".

The only platform I know where config.guess' output depends on both the
kernel-bits and compiler-bits (${CC_FOR_BUILD:-${HOST_CC:-${CC}}}) is
HP-UX on PA/RISC:
hppa1*-hp-hpux*:      32bit CPU
hppa2.0-hp-hpux10.20: 64bit CPU, but HP-UX 10.20 is 32bit only.
hppa2.0n-hp-hpux11.*: 64bit CPU, 32bit (narrow) kernel.
hppa2.0w-hp-hpux11.*: 64bit CPU, 64bit (wide) kernel, 32bit $CC output.
hppa64-hp-hpux11.*:   64bit CPU, 64bit kernel, 64bit $CC output.

> 
> > What I could think of is something like this:
> > 
> > 1) For "CHOST=ia64-hp-hpux*", patch toolchain (or set CFLAGS/LDFLAGS) to
> > default to 64bit, and use keyword 'ia64-hpux'.
> 
> We have similar patches for Solaris on x64, so I don't think this is a
> big issue to do.
> 
> > 2a) Define a new "CHOST=ia64_32-hp-hpux*", patch toolchain to understand
> > this (like for x64-solaris iirc?), and use keyword 'ia64_32-hpux'.
> 
> Quite ugly, but I guess sort of necessary.
> 
> > 2b) Or should this better be named "CHOST=ia32-hp-hpux*" and keyword
> > 'ia32-hpux' ?
> 
> Question is whether ia32 technically is what you get with this 32-bits
> emulation on ia64.  (I thought ia32 was just regular x86 stuff, but I
> can be wrong here.  The ia64-architecture isn't compatible with i386 IMO.)
> 
> > How would this be confusing with the fact that 'ia32' is equal to 'x86'
> > from Intel's POV (they use 'x64' for 'x86' + EM64T extension IIRC).
> 
> Ah, I should "read ahead".
> 
> Yeah.  x64 is kind of loaded with negative feelings from the other
> Gentoo folks, basically because Microsoft uses it.  However, I still
> like it that we chose to use it, as it's more generic than amd64 is.
> (Convert amd64-linux to x64-linux as well?)

x86w-{solaris,linux} ? ("wide", see below)

> How necessary is the 32-bits environment for hpux?

Well, our application is still not 64bit aware at all, so we need 32bit
even on ia64-hpux, x86_64-linux, x86_64-solaris, ppc64-aix and cannot
support ia64-linux ATM.

>   I think ia64_32 comes closest to something we've seen before (x86_64),
>  so we better use that then in the CHOST.

The x86_64 affinity was my idea behind ia64_32 indeed.
But do we really need a separate CHOST ?
Why cannot we use CFLAGS=-m[64|32] to switch the bitwidth, eventually
built into gcc-wrapper with some intelligence ?

Hmm, might be too confusing if "ia64-hp-hpux11.23-gcc" produces
different bitwidths in different prefixes on same machine without seeing
any additional argument.

>   Makes a bit of a problem what we're going to use in our keywords.

Simply because of the '_' you also didn't choose 'x86_64-solaris' ?

> I think ia32 is a techical unforgivable suggestion, i32 could do for me, though not really a beauty.

Hmm, 'i32' is too short IMO.
More ideas for both the 64bit- and 32bit-keyword:
 ia64-hpux and ia64n-hpux  ("narrow", borrowed from hppa2.0n-hp-hpux11*)
 ia64-hpux and it32-hpux   ("ia64" and "Itanium 32bit")
 it64-hpux and it32-hpux   (both from "Itanium")
 ia64-hpux and ia6432-hpux (huh, too many bits)

Looking at this, my favorite is 'ia64-hpux' and 'ia64n-hpux'...

> Maybe we really have no choice but to keep the keyword the same (the arch
> technically IS ia64, right?) as we're dealing with an emulation mode,
> and only have the profile to switch to the right CHOST (and hence get
> the right compiler)?

Then I'd more appreciate to have two keywords with same CHOST and
appropriate CFLAGS than the other way round.

> Not sure what the packages broken/wordsize ratio is for HPUX in this case.

For our application it's simply too high ;)

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level

-- 
gentoo-alt@g.o mailing list