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