1 |
So we're one step closer to getting multilib toolchain to the point |
2 |
where we can drop ABI and base everything off of CHOST. I just |
3 |
committed eselect-compiler to portage (in package.mask) which will be |
4 |
replacing gcc-config. If you'd like to test it out, add the following |
5 |
to /etc/portage/package.unmask: |
6 |
|
7 |
app-admin/eselect-compiler |
8 |
sys-devel/gcc-config |
9 |
|
10 |
Most of the gcc-config commands should be the same, but you have a bit |
11 |
more control using 'eselect compiler'. If you've emerged gcc within the |
12 |
last week, then you'll have the multilib profiles automatically. If |
13 |
not, the upgrade process tries to set it up for you automatically. It |
14 |
works fine for the normal user, but it's not smart enough to figure out |
15 |
how to create the multilib profiles, so you'll either have to re-emerge |
16 |
gcc or edit the configs in /etc/eselect/compiler yourself (see attached |
17 |
examples). |
18 |
|
19 |
If you edit the configs manually, do a 'eselect compiler update' to make |
20 |
sure the wrappers are up to date. This will result in you having an |
21 |
i686-pc-linux-gnu- prefixed compiler set rather than using 'gcc32' or |
22 |
remembering the '-m32' in CFLAGS. You can also use a separate version |
23 |
and specs for the x86 and amd64 toolchains this way. |
24 |
|
25 |
Please test this out, break it, and send me feedback and patches. Once |
26 |
this gets cleaned up and hammered out, we can do the same for |
27 |
binutils-config as well... |
28 |
|
29 |
Thanks, |
30 |
Jeremy |