1 |
On Thu, 2008-05-15 at 12:32 +0200, Fabian Groffen wrote: |
2 |
> On 15-05-2008 11:58:50 +0200, Michael Haubenwallner wrote: |
3 |
> > Hi, |
4 |
> > |
5 |
> > While 'ia64-hpux' is a multilib platform, and the compilers (HP-cc, gcc) |
6 |
> > support this, their default output still is 32bit. |
7 |
> > |
8 |
> > This is the reason why currently the 'ia64-hpux' keyword in prefix |
9 |
> > stands for 32bit, but IMO this is just wrong. |
10 |
> |
11 |
> Feels really wrong indeed. They just do like any other UNIX does, but |
12 |
> on a 64-bits chip. |
13 |
|
14 |
Hmm, can't understand the "but" here: don't we have this problem for any |
15 |
multilib-capable Unix too (you hacked sth. for Solaris already) ? |
16 |
|
17 |
Fex config.guess does not know "powerpc64-ibm-aix*" on a 64bit |
18 |
AIX-kernel, it's still "powerpc-ibm-aix*". |
19 |
|
20 |
The only platform I know where config.guess' output depends on both the |
21 |
kernel-bits and compiler-bits (${CC_FOR_BUILD:-${HOST_CC:-${CC}}}) is |
22 |
HP-UX on PA/RISC: |
23 |
hppa1*-hp-hpux*: 32bit CPU |
24 |
hppa2.0-hp-hpux10.20: 64bit CPU, but HP-UX 10.20 is 32bit only. |
25 |
hppa2.0n-hp-hpux11.*: 64bit CPU, 32bit (narrow) kernel. |
26 |
hppa2.0w-hp-hpux11.*: 64bit CPU, 64bit (wide) kernel, 32bit $CC output. |
27 |
hppa64-hp-hpux11.*: 64bit CPU, 64bit kernel, 64bit $CC output. |
28 |
|
29 |
> |
30 |
> > What I could think of is something like this: |
31 |
> > |
32 |
> > 1) For "CHOST=ia64-hp-hpux*", patch toolchain (or set CFLAGS/LDFLAGS) to |
33 |
> > default to 64bit, and use keyword 'ia64-hpux'. |
34 |
> |
35 |
> We have similar patches for Solaris on x64, so I don't think this is a |
36 |
> big issue to do. |
37 |
> |
38 |
> > 2a) Define a new "CHOST=ia64_32-hp-hpux*", patch toolchain to understand |
39 |
> > this (like for x64-solaris iirc?), and use keyword 'ia64_32-hpux'. |
40 |
> |
41 |
> Quite ugly, but I guess sort of necessary. |
42 |
> |
43 |
> > 2b) Or should this better be named "CHOST=ia32-hp-hpux*" and keyword |
44 |
> > 'ia32-hpux' ? |
45 |
> |
46 |
> Question is whether ia32 technically is what you get with this 32-bits |
47 |
> emulation on ia64. (I thought ia32 was just regular x86 stuff, but I |
48 |
> can be wrong here. The ia64-architecture isn't compatible with i386 IMO.) |
49 |
> |
50 |
> > How would this be confusing with the fact that 'ia32' is equal to 'x86' |
51 |
> > from Intel's POV (they use 'x64' for 'x86' + EM64T extension IIRC). |
52 |
> |
53 |
> Ah, I should "read ahead". |
54 |
> |
55 |
> Yeah. x64 is kind of loaded with negative feelings from the other |
56 |
> Gentoo folks, basically because Microsoft uses it. However, I still |
57 |
> like it that we chose to use it, as it's more generic than amd64 is. |
58 |
> (Convert amd64-linux to x64-linux as well?) |
59 |
|
60 |
x86w-{solaris,linux} ? ("wide", see below) |
61 |
|
62 |
> How necessary is the 32-bits environment for hpux? |
63 |
|
64 |
Well, our application is still not 64bit aware at all, so we need 32bit |
65 |
even on ia64-hpux, x86_64-linux, x86_64-solaris, ppc64-aix and cannot |
66 |
support ia64-linux ATM. |
67 |
|
68 |
> I think ia64_32 comes closest to something we've seen before (x86_64), |
69 |
> so we better use that then in the CHOST. |
70 |
|
71 |
The x86_64 affinity was my idea behind ia64_32 indeed. |
72 |
But do we really need a separate CHOST ? |
73 |
Why cannot we use CFLAGS=-m[64|32] to switch the bitwidth, eventually |
74 |
built into gcc-wrapper with some intelligence ? |
75 |
|
76 |
Hmm, might be too confusing if "ia64-hp-hpux11.23-gcc" produces |
77 |
different bitwidths in different prefixes on same machine without seeing |
78 |
any additional argument. |
79 |
|
80 |
> Makes a bit of a problem what we're going to use in our keywords. |
81 |
|
82 |
Simply because of the '_' you also didn't choose 'x86_64-solaris' ? |
83 |
|
84 |
> I think ia32 is a techical unforgivable suggestion, i32 could do for me, though not really a beauty. |
85 |
|
86 |
Hmm, 'i32' is too short IMO. |
87 |
More ideas for both the 64bit- and 32bit-keyword: |
88 |
ia64-hpux and ia64n-hpux ("narrow", borrowed from hppa2.0n-hp-hpux11*) |
89 |
ia64-hpux and it32-hpux ("ia64" and "Itanium 32bit") |
90 |
it64-hpux and it32-hpux (both from "Itanium") |
91 |
ia64-hpux and ia6432-hpux (huh, too many bits) |
92 |
|
93 |
Looking at this, my favorite is 'ia64-hpux' and 'ia64n-hpux'... |
94 |
|
95 |
> Maybe we really have no choice but to keep the keyword the same (the arch |
96 |
> technically IS ia64, right?) as we're dealing with an emulation mode, |
97 |
> and only have the profile to switch to the right CHOST (and hence get |
98 |
> the right compiler)? |
99 |
|
100 |
Then I'd more appreciate to have two keywords with same CHOST and |
101 |
appropriate CFLAGS than the other way round. |
102 |
|
103 |
> Not sure what the packages broken/wordsize ratio is for HPUX in this case. |
104 |
|
105 |
For our application it's simply too high ;) |
106 |
|
107 |
/haubi/ |
108 |
-- |
109 |
Michael Haubenwallner |
110 |
Gentoo on a different level |
111 |
|
112 |
-- |
113 |
gentoo-alt@l.g.o mailing list |