On 09/15/2011 10:34 PM, Mike Frysinger wrote: > ive converted my system over to x86/amd64/x32 multilib for funs. but i can > see how some people wont want all three all the time. so the question is how > we want to make this available to users at the release/profile level. > > background: x32 is a new ABI that runs on 64bit x86_64 processors. see [1]. > you'll need gcc-4.7+, binutils-2.21.50+, glibc-2.15+, and linux-3.2+. > > KEYWORDS wise, i'd like to avoid having to add "x32" everywhere. instead, > reusing "amd64". only downside is the existing USE=amd64 behavior, but we > can > address that by making MULTILIB_ABIS a USE_EXPAND (i think this came up > before > with the portage multilib discussion). > > release wise, we could ship a single multilib stage (x86/amd64/x32) and make > it easy to convert to a subset. that way we still need only one. > > other thoughts ? > -mike > > [1] https://sites.google.com/site/x32abi/ Is a x86/amd64/x32 multilib profile just going to provide toolchain support for x32 binaries (like x86 in a x86/amd64 multilib profile), or do we want a 'full' x32 profile, where every package is built by default as x32 code?
I'm guessing that as x32 gets standarized, and providing it really outperforms amd64, most distros we'll move to using x32 binaries/libs by default. But then, what if a user wants amd64 for specific packages, which depend on shared libraries built as x32 (maybe he should just use the amd64 profile then)? -- Stratos Psomadakis <pso...@gentoo.org>
