On Fri, Mar 8, 2013 at 10:47 AM, W. Trevor King <[email protected]> wrote: > From: "W. Trevor King" <[email protected]> > > When using `update_seed` to get a 20121213 stage3 from > libmpc.so.2 to libmpc.so.3, stage2 failed with: > > /usr/libexec/gcc/i686-pc-linux-gnu/4.6.3/cc1: > error while loading shared libraries: libmpc.so.2: > cannot open shared object file: No such file or directory
gcc installed into the stage1 should not be linked against libmpc.so.2. Something is wrong. > This was due to an mpc version bump in the Portage tree that was not > present in the stage3 I used to seed stage1. Stage1 wasn't > recompiling GCC against the new mpc, so it ended up with GCC linking > against the old mpc. This is really your problem. gcc is built in stage1 and with an updated mpc built during update_seed. The only way I can think of that gcc could be linked against libmpc.so.2 in stage1 is if a binpkg of gcc was used. > Heading into stage2, the old mpc (from the seed > stage3) was no longer present, so compilation crashed and burned. > > To fix this, we should be extra agressive about rebuilding packages > when their dependencies change in stage1. No, we shouldn't, because we don't care about stage1. We simply want the seed stage to be sufficient to produce a working stage1. By the time we get to stage3 everything has been rebuilt against the latest package versions. > The earlier update_seed > command was not catching the bumped mpc, so add: I think this is a false premise. If it is true, we should understand why and fix it. The current command is emerge --onlydeps gcc which should be completely sufficient to update mpc. > > --complete-graph --with-bdeps=y --rebuild-if-new-ver > > to toughen things up. > > This is a general dependency problem (not GCC specific), so I also > replaced the gcc target with: > > @world @system > > This leads to a lot of rebuilding, but it should be a stable and > general fix. With a general fix there should be no more need for > user-specific overrides via update_seed_command, but Gentoo is about > choice, so we keep the option. Use it at your own risk ;). > > Based-on-patch-by: Brian Dolbec <[email protected]> > --- > Changes since v2: > * Reinstated update_seed_command, as requested by Zero_Chaos. > > doc/catalyst-spec.5.txt | 2 +- > targets/stage1/stage1-chroot.sh | 9 +++------ > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/doc/catalyst-spec.5.txt b/doc/catalyst-spec.5.txt > index 4a6e06c..0eb3c2f 100644 > --- a/doc/catalyst-spec.5.txt > +++ b/doc/catalyst-spec.5.txt > @@ -138,7 +138,7 @@ it should update the seed stage or not (valid values: > `yes no`). > *update_seed_command*:: > This is an optional command to pass to emerge for updating the seed > stage (example: `--update dev-libs/mpfr dev-libs/mpc dev-libs/gmp`) > -If not specified, catalyst will update gcc deps. > +If not specified, catalyst will update `@system` and `@world`. > This setting requires enabling update_seed. > > Compilation > diff --git a/targets/stage1/stage1-chroot.sh b/targets/stage1/stage1-chroot.sh > index 3f628c2..0e3859c 100644 > --- a/targets/stage1/stage1-chroot.sh > +++ b/targets/stage1/stage1-chroot.sh > @@ -26,12 +26,9 @@ clst_root_path=/ setup_pkgmgr > # Update stage3 > if [ -n "${clst_update_seed}" ]; then > if [ "${clst_update_seed}" == "yes" ]; then > - echo "Updating seed stage..." > - if [ -n "${clst_update_seed_command}" ]; then > - clst_root_path=/ run_merge "--buildpkg=n > ${clst_update_seed_command}" > - else > - clst_root_path=/ run_merge "--buildpkg=n --update > --deep --newuse --onlydeps gcc" > - fi > + update_cmd="${clst_update_seed_command:---update --deep > --complete-graph --with-bdeps=y --rebuild-if-new-ver @world @system}" > + echo "--- Updating seed stage with: ${update_cmd}" > + clst_root_path=/ run_merge "${update_cmd}" > elif [ "${clst_update_seed}" != "no" ]; then > echo "Invalid setting for update_seed: ${clst_update_seed}" > exit 1 > -- > 1.8.2.rc0.16.g20a599e
