| 1 |
On Sat, 2013-07-06 at 00:08 -0700, Matt Turner wrote: |
| 2 |
> On Fri, Jul 5, 2013 at 7:18 PM, Rick "Zero_Chaos" Farina |
| 3 |
> <zerochaos@g.o> wrote: |
| 4 |
> > When we then move onto stage 2, it uses just the packages built during |
| 5 |
> > stage1 (/tmp/stage1root becomes /). This means, if seed stage has |
| 6 |
> > mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in |
| 7 |
> > stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. |
| 8 |
> > |
| 9 |
> > To combat this kind of failure we are currently running "emerge --update |
| 10 |
> > - --deep --newuse --complete-graph --rebuild-if-new-ver gcc" which could |
| 11 |
> > just be "emerge --update gcc" if eapi 5 subslots were used properly. |
| 12 |
> |
| 13 |
> The best solution to this is, and has always been, just updating gcc's |
| 14 |
> deps during update_seed. Or am I misremembering something? |
| 15 |
> |
| 16 |
> As far as I know, you don't need to waste time rebuilding the seed |
| 17 |
> stage's gcc, since gcc is rebuilt in stage2 and then everything is |
| 18 |
> built by it in stage3. |
| 19 |
> |
| 20 |
|
| 21 |
Yes, it does need to be rebuilt if key deps are updated. The gcc |
| 22 |
produced in the stage1 is broken, so won't run to rebuild itself during |
| 23 |
the stage2 run. |
| 24 |
Also the "--rebuild-if-new-ver gcc" only rebuilds gcc if it's deps are |
| 25 |
updated to new versions (likely breaking lib linkage), it is not |
| 26 |
unconditional. It is not as accurate as subslots, so may rebuild more |
| 27 |
often than possibly needed. But it is better than having unreliable |
| 28 |
stage builds, not knowing when they may break. |
| 29 |
-- |
| 30 |
Brian Dolbec <dolsen@g.o> |
Archives