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