| 1 |
On Fri, Jul 5, 2013 at 7:18 PM, Rick "Zero_Chaos" Farina |
| 2 |
<zerochaos@g.o> wrote: |
| 3 |
> When we then move onto stage 2, it uses just the packages built during |
| 4 |
> stage1 (/tmp/stage1root becomes /). This means, if seed stage has |
| 5 |
> mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in |
| 6 |
> stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. |
| 7 |
> |
| 8 |
> To combat this kind of failure we are currently running "emerge --update |
| 9 |
> - --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could |
| 10 |
> just be "emerge --update gcc" if eapi 5 subslots were used properly. |
| 11 |
|
| 12 |
The best solution to this is, and has always been, just updating gcc's |
| 13 |
deps during update_seed. Or am I misremembering something? |
| 14 |
|
| 15 |
As far as I know, you don't need to waste time rebuilding the seed |
| 16 |
stage's gcc, since gcc is rebuilt in stage2 and then everything is |
| 17 |
built by it in stage3. |
Archives