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 breakage. 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 case. 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
