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