I've chosen severity=critical because literally following the steps suggested results in a library broken system: the "emerge sys-libs/libstdc++-v3" command must be executed both before and after the change of the default compiler. Infact in section 3 ("Upgrading from GCC-3.3 to 3.4") both the quick and the slow method lack a warning: if you do the gcc-config change of default compiler, you must have already installed the sys-libs/libstdc++-v3. You can't install it later, because the library cache in ld.so.conf and ld.so.cache miss the necessary library required by python: emerge will not even load the interpreter, halting with a 'libstdc++.so.5: file or directory unavailable'. Should you arrive at this point, only 1) manual editing of ld.so.conf restoring the 3.3.x values and 2) ldconfig -v can recover the old environment to emerge the required package. Or did I miss something?
If you still have gcc-3.3 installed, you don't need libstdc++ _at all_.
I guess a call to ldconfig should be thrown in there to update the cache. If you follow the directions, python should not be linked to libstdc++.so.5, but ld.so.cache won't be updated after libstdc++-v3 is merged, so there _could_ be some breakage I guess.
Portage should call env_update() at the end of every merge() or unmerge(), at least that's what I've read from the sources. env_update() should call `ldconfig` if needed. Anyway, feel free to reopen if you reproduce it.
Reproduced, but it was due to an error. The old hardware system I tested with had the old toolchain compiled with a i386 CHOST (stage3-2005-r1), and the new gcc with a i586 mcpu. Then, after a gcc-config swith, the ldconfig in env-update caused the loss of the i386 libraries location.
