Gentoo Archives: gentoo-alt

From: Fabian Groffen <grobian@g.o>
To: gentoo-alt@l.g.o
Subject: Re: [gentoo-alt] [prefix] ia64-hpux keyword and 32bit/64bit
Date: Mon, 08 Mar 2010 15:52:36
In Reply to: Re: [gentoo-alt] [prefix] ia64-hpux keyword and 32bit/64bit by Michael Haubenwallner
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' ?
> > 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