1 |
Mike Frysinger posted on Thu, 15 Sep 2011 17:18:43 -0400 as excerpted: |
2 |
|
3 |
> On Thursday, September 15, 2011 17:03:07 Michał Górny wrote: |
4 |
>> On Thu, 15 Sep 2011 16:33:48 -0400 Mike Frysinger wrote: |
5 |
>> > On Thursday, September 15, 2011 16:12:00 Michał Górny wrote: |
6 |
>> > > On Thu, 15 Sep 2011 15:34:06 -0400 Mike Frysinger wrote: |
7 |
>> > > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. |
8 |
>> > > > instead, reusing "amd64". |
9 |
|
10 |
>> > > Hrm, wouldn't that be more like x86 keyword? AFAICS the type sizes |
11 |
>> > > for x86 and x32 would match. |
12 |
>> > |
13 |
>> > the sizeof(long) and sizeof(void*) are the same between x86 and x32. |
14 |
>> > however, that's about the only thing. for example, x32 gets access |
15 |
>> > to 64bit registers when working with 64bit types (long long) and the |
16 |
>> > tuple is x86_64-pc-linux- gnu. in general, it seems to be closer to |
17 |
>> > amd64 than x32. |
18 |
>> |
19 |
>> I'm rather thinking about potential issues. But OTOH packages fixed for |
20 |
>> amd64 should probably work with x32 as well. Excluding asm code which |
21 |
>> would probably need a third variant then. |
22 |
> |
23 |
> yes, inline asm might need tweaking[.] |
24 |
> they'll need to have gcc take care of it |
25 |
|
26 |
> but i'd rather not introduce another KEYWORD when we can simply p.mask |
27 |
> the package, or disable the asm when ABI == x32. |
28 |
|
29 |
My immediate thought, probably unworkable for some reason but from here |
30 |
it looks useful for at least (what would be) ~x32 and as a jump-start on |
31 |
the number of ~x32 packages, and it should at least prove educational to |
32 |
have it shot down (<g>)... |
33 |
|
34 |
Have an x32 keyword, but at least for ~arch, have the package managers |
35 |
(or profiles) define some "magic" such that ~amd64 AND ~x86 == ~x32 |
36 |
(likely as EAPI-N, if delegated to the package managers). |
37 |
|
38 |
It seems to me that if the package is ~arch keyworded for both ~amd64 and |
39 |
~x86, it should be reasonable to consider it ~x32 as well, and that would |
40 |
enormously jump-start the available packages list and remove the |
41 |
necessity of adding all those keywords. |
42 |
|
43 |
Further, -x32 could then be used for specific cases where ~x32 was NOT |
44 |
desired from the combined ~x86/~amd64 keywords, and as packages were |
45 |
actually tested stable, they could be x32 stable-keyworded or -x32 |
46 |
keyworded (or profile package.masked) as appropriate. |
47 |
|
48 |
The same could obviously be tried for x32-stable based on x86 AND amd64, |
49 |
but that seems far more problematic, while the existing practice of |
50 |
simply carrying forward ~arch keywords without individually testing each |
51 |
~arch is only extended slightly, and ~arch users (no matter the arch) |
52 |
should already by policy be prepared to cope with and fix occasional |
53 |
breakage. |
54 |
|
55 |
OK, shoot it down. =:^) |
56 |
|
57 |
Or do as suggested elsewhere and combine all three into ABIs of the same |
58 |
arch keyword, making the issue moot. This is the best excuse we're ever |
59 |
likely to get, for that, and over time as it deprecates, I expect legacy |
60 |
x86 to appreciate the extra arch-team manpower they'd otherwise be losing |
61 |
as they faded into minority and eventually obscurity. And with x32, the |
62 |
cooperation between the two existing arch-abis will need to grow, in any |
63 |
case. |
64 |
|
65 |
But whether it's arch-team politically feasible, I don't know... I |
66 |
believe that's what stopped the idea the last time it came up, but that |
67 |
was before this whole x32 thing, which does quite change things. |
68 |
|
69 |
-- |
70 |
Duncan - List replies preferred. No HTML msgs. |
71 |
"Every nonfree program has a lord, a master -- |
72 |
and if you use the program, he is your master." Richard Stallman |