I recently bootstrapped on an ia64-hpux box (cannot keep it/maintain it
unfortunately), so I ran into this problem as well...

On 15-05-2008 22:06:46 +0200, Michael Haubenwallner wrote:
> On Thu, 2008-05-15 at 12:32 +0200, Fabian Groffen wrote:
> > On 15-05-2008 11:58:50 +0200, Michael Haubenwallner wrote:
> > > 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) ?

I think the difference is that sparc still reports itself as sparc, not
sparcv9, and amd64 reports itself as i386 even on a 64-bits kernel
Solaris.  ia64 is 64-bits only on Linux, which makes things worse;
people think it's a 64-bits only cpu.

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

Yeah, that's because x86_64-pc-solaris2.* doesn't exist either.  Only
sparc seems old enough to have grown a sparcv9-sun-solaris2.* thingy.

The idea stems from the fact that we don't want a multilib compiler that
targets 32-bits by default, but one that isn't multilib and produces
64-bits code.

> 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.

The last line sort of matches with what we do on Solaris, Darwin and
Linux.

> > > 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 32-bits is inevitable, already because it's the default of the
OS itself.  I somehow don't like the idea of changing the bitwidth of
existing ia64-hpux installs.

> >   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 ?

I think it used to have some of such logic, but requires a multilib
compiler, which imo is asking for trouble.

> 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.

I think the CHOST must identify in some way what the bitwidth is, just
for the sake of sanity.  Even if that would mean ia6464-* or ia64w-*.

> >   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' ?

yes

> > 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'...

Hmmm, I somehow like it64-hpux and it32-hpux the most, easy to make the
keyword switch, but the more alignment we can get with the chost, the
better.  In that sense, I can live with ia64w-hpux too.

> > 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.

Hmmm but that means we cannot distinguish between the two...

> > Not sure what the packages broken/wordsize ratio is for HPUX in this case.
> 
> For our application it's simply too high ;)

I had a request to bootstrap a 64-bits Prefix on ia64-hpux, so given
this discussion I fear a high failure rate of packages even more than
the 32-bits bootstrap gave me.  (prefix-launcher seems to need a major
boost/update to get up2date)


-- 
Fabian Groffen
Gentoo on a different level