1 |
I recently bootstrapped on an ia64-hpux box (cannot keep it/maintain it |
2 |
unfortunately), so I ran into this problem as well... |
3 |
|
4 |
On 15-05-2008 22:06:46 +0200, Michael Haubenwallner wrote: |
5 |
> On Thu, 2008-05-15 at 12:32 +0200, Fabian Groffen wrote: |
6 |
> > On 15-05-2008 11:58:50 +0200, Michael Haubenwallner wrote: |
7 |
> > > While 'ia64-hpux' is a multilib platform, and the compilers (HP-cc, gcc) |
8 |
> > > support this, their default output still is 32bit. |
9 |
> > > |
10 |
> > > This is the reason why currently the 'ia64-hpux' keyword in prefix |
11 |
> > > stands for 32bit, but IMO this is just wrong. |
12 |
> > |
13 |
> > Feels really wrong indeed. They just do like any other UNIX does, but |
14 |
> > on a 64-bits chip. |
15 |
> |
16 |
> Hmm, can't understand the "but" here: don't we have this problem for any |
17 |
> multilib-capable Unix too (you hacked sth. for Solaris already) ? |
18 |
|
19 |
I think the difference is that sparc still reports itself as sparc, not |
20 |
sparcv9, and amd64 reports itself as i386 even on a 64-bits kernel |
21 |
Solaris. ia64 is 64-bits only on Linux, which makes things worse; |
22 |
people think it's a 64-bits only cpu. |
23 |
|
24 |
> Fex config.guess does not know "powerpc64-ibm-aix*" on a 64bit |
25 |
> AIX-kernel, it's still "powerpc-ibm-aix*". |
26 |
|
27 |
Yeah, that's because x86_64-pc-solaris2.* doesn't exist either. Only |
28 |
sparc seems old enough to have grown a sparcv9-sun-solaris2.* thingy. |
29 |
|
30 |
The idea stems from the fact that we don't want a multilib compiler that |
31 |
targets 32-bits by default, but one that isn't multilib and produces |
32 |
64-bits code. |
33 |
|
34 |
> hppa1*-hp-hpux*: 32bit CPU |
35 |
> hppa2.0-hp-hpux10.20: 64bit CPU, but HP-UX 10.20 is 32bit only. |
36 |
> hppa2.0n-hp-hpux11.*: 64bit CPU, 32bit (narrow) kernel. |
37 |
> hppa2.0w-hp-hpux11.*: 64bit CPU, 64bit (wide) kernel, 32bit $CC output. |
38 |
> hppa64-hp-hpux11.*: 64bit CPU, 64bit kernel, 64bit $CC output. |
39 |
|
40 |
The last line sort of matches with what we do on Solaris, Darwin and |
41 |
Linux. |
42 |
|
43 |
> > > What I could think of is something like this: |
44 |
> > > |
45 |
> > > 1) For "CHOST=ia64-hp-hpux*", patch toolchain (or set CFLAGS/LDFLAGS) to |
46 |
> > > default to 64bit, and use keyword 'ia64-hpux'. |
47 |
> > |
48 |
> > We have similar patches for Solaris on x64, so I don't think this is a |
49 |
> > big issue to do. |
50 |
> > |
51 |
> > > 2a) Define a new "CHOST=ia64_32-hp-hpux*", patch toolchain to understand |
52 |
> > > this (like for x64-solaris iirc?), and use keyword 'ia64_32-hpux'. |
53 |
> > |
54 |
> > Quite ugly, but I guess sort of necessary. |
55 |
> > |
56 |
> > > 2b) Or should this better be named "CHOST=ia32-hp-hpux*" and keyword |
57 |
> > > 'ia32-hpux' ? |
58 |
> > |
59 |
> > Question is whether ia32 technically is what you get with this 32-bits |
60 |
> > emulation on ia64. (I thought ia32 was just regular x86 stuff, but I |
61 |
> > can be wrong here. The ia64-architecture isn't compatible with i386 IMO.) |
62 |
> > |
63 |
> > > How would this be confusing with the fact that 'ia32' is equal to 'x86' |
64 |
> > > from Intel's POV (they use 'x64' for 'x86' + EM64T extension IIRC). |
65 |
> > |
66 |
> > Ah, I should "read ahead". |
67 |
> > |
68 |
> > Yeah. x64 is kind of loaded with negative feelings from the other |
69 |
> > Gentoo folks, basically because Microsoft uses it. However, I still |
70 |
> > like it that we chose to use it, as it's more generic than amd64 is. |
71 |
> > (Convert amd64-linux to x64-linux as well?) |
72 |
> |
73 |
> x86w-{solaris,linux} ? ("wide", see below) |
74 |
> |
75 |
> > How necessary is the 32-bits environment for hpux? |
76 |
> |
77 |
> Well, our application is still not 64bit aware at all, so we need 32bit |
78 |
> even on ia64-hpux, x86_64-linux, x86_64-solaris, ppc64-aix and cannot |
79 |
> support ia64-linux ATM. |
80 |
|
81 |
I think 32-bits is inevitable, already because it's the default of the |
82 |
OS itself. I somehow don't like the idea of changing the bitwidth of |
83 |
existing ia64-hpux installs. |
84 |
|
85 |
> > I think ia64_32 comes closest to something we've seen before (x86_64), |
86 |
> > so we better use that then in the CHOST. |
87 |
> |
88 |
> The x86_64 affinity was my idea behind ia64_32 indeed. |
89 |
> But do we really need a separate CHOST ? |
90 |
> Why cannot we use CFLAGS=-m[64|32] to switch the bitwidth, eventually |
91 |
> built into gcc-wrapper with some intelligence ? |
92 |
|
93 |
I think it used to have some of such logic, but requires a multilib |
94 |
compiler, which imo is asking for trouble. |
95 |
|
96 |
> Hmm, might be too confusing if "ia64-hp-hpux11.23-gcc" produces |
97 |
> different bitwidths in different prefixes on same machine without seeing |
98 |
> any additional argument. |
99 |
|
100 |
I think the CHOST must identify in some way what the bitwidth is, just |
101 |
for the sake of sanity. Even if that would mean ia6464-* or ia64w-*. |
102 |
|
103 |
> > Makes a bit of a problem what we're going to use in our keywords. |
104 |
> |
105 |
> Simply because of the '_' you also didn't choose 'x86_64-solaris' ? |
106 |
|
107 |
yes |
108 |
|
109 |
> > I think ia32 is a techical unforgivable suggestion, i32 could do for me, though not really a beauty. |
110 |
> |
111 |
> Hmm, 'i32' is too short IMO. |
112 |
> More ideas for both the 64bit- and 32bit-keyword: |
113 |
> ia64-hpux and ia64n-hpux ("narrow", borrowed from hppa2.0n-hp-hpux11*) |
114 |
> ia64-hpux and it32-hpux ("ia64" and "Itanium 32bit") |
115 |
> it64-hpux and it32-hpux (both from "Itanium") |
116 |
> ia64-hpux and ia6432-hpux (huh, too many bits) |
117 |
> |
118 |
> Looking at this, my favorite is 'ia64-hpux' and 'ia64n-hpux'... |
119 |
|
120 |
Hmmm, I somehow like it64-hpux and it32-hpux the most, easy to make the |
121 |
keyword switch, but the more alignment we can get with the chost, the |
122 |
better. In that sense, I can live with ia64w-hpux too. |
123 |
|
124 |
> > Maybe we really have no choice but to keep the keyword the same (the arch |
125 |
> > technically IS ia64, right?) as we're dealing with an emulation mode, |
126 |
> > and only have the profile to switch to the right CHOST (and hence get |
127 |
> > the right compiler)? |
128 |
> |
129 |
> Then I'd more appreciate to have two keywords with same CHOST and |
130 |
> appropriate CFLAGS than the other way round. |
131 |
|
132 |
Hmmm but that means we cannot distinguish between the two... |
133 |
|
134 |
> > Not sure what the packages broken/wordsize ratio is for HPUX in this case. |
135 |
> |
136 |
> For our application it's simply too high ;) |
137 |
|
138 |
I had a request to bootstrap a 64-bits Prefix on ia64-hpux, so given |
139 |
this discussion I fear a high failure rate of packages even more than |
140 |
the 32-bits bootstrap gave me. (prefix-launcher seems to need a major |
141 |
boost/update to get up2date) |
142 |
|
143 |
|
144 |
-- |
145 |
Fabian Groffen |
146 |
Gentoo on a different level |