1 |
On Wednesday 07 December 2011 17:15:47 Mike Frysinger wrote: |
2 |
> the advantage is that it should obsolete the separate kgcc64 package for |
3 |
> most people. and i think it might help out with the multilib bootstrap |
4 |
> issue: you can't build multilib gcc without a multilib glibc, and can't |
5 |
> build a multilib glibc without a multilib gcc, but i think you should be |
6 |
> able to build a multilib glibc with a multiarch gcc, and then a multilib |
7 |
> gcc after that. |
8 |
|
9 |
a followup: have glibc always install headers for all possible ABIs. this |
10 |
might sound like a lot, but in practice, it amounts to only a handful as glibc |
11 |
by default includes support for all ABIs in common headers. |
12 |
|
13 |
the most common example: |
14 |
- amd64 ABI has one unshared header: gnu/stubs-64.h |
15 |
- x86 ABI has three unshared headers: gnu/stubs-32.h sys/elf.h sys/vm86.h |
16 |
|
17 |
so the overhead we're talking about here is that nomultilib amd64 systems will |
18 |
have 3 additional headers installed, and nomultilib x86 systems will have one |
19 |
extra header. i suspect the overhead will be very similar for all arches. |
20 |
|
21 |
the reason for doing this is to try and make multilib migration simpler. with |
22 |
this change in place, you should be able to "upgrade" from a nomultilib amd64 |
23 |
profile to a multilib amd64 profile with: |
24 |
USE='-*' emerge sys-devel/gcc |
25 |
emerge sys-libs/glibc |
26 |
emerge sys-devel/gcc |
27 |
|
28 |
still not as automatic as i'd like, but getting closer ... |
29 |
-mike |