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