You *cannot* unmerge a version / configuration of GCC when some packages built with it still exist. Doing so will lead to all sorts of problems. For example the numerous bugreports related to miscompilations due to missing libstdc++ are possibly only various manifestations of this bug. Steps to demonstrate why you cannot unmerge gcc while code generated for it is still installed in the system: 1. Emerge gcc-3.4.3 2. Emerge some C++ libraries (e.g. libsdl) 3. Upgrade world (do an "emerge --update world") This will emerge gcc-3.4.4 4. Unmerge gcc-3.4.3 if the previous step didn't do it. But do *not* do this directly (via command like "emerge --unmerge gcc"). Do an "emerge --depclean" instead. 5. Now the library built in step 2 is broken. It is impossible to link against it. If you try, you will get a failure with a missing libstdc++ library. Why? The step 4 (or 3) *unmerges* the gcc-3.4.3 even when it is still in use !!! Namely the libsdl merged in step 2 uses libstdc++ from gcc 3.4.3. Unmerging the gcc-3.4.3 also unmerges the libstdc++ library the libsdl is linked against breaking the libsdl. To see this is really true look into /usr/lib/libsdl-*.la after the step 2 completes. You will see references to libsdtc++ in gcc-3.4.3 (grep the file against "gcc\-3\.4\.3" regexp, you will get at least one line). The worst thing here is that when you have such a broken library, you *cannot* easily find it. Even when you try to link against a broken library, you don't even get a mention of its name. You will get a name of a component of the deleted compiler instead. The problem will also manifest when you try to link something against the affected library. The broken library can be fixed by emerging it again. ... if portage is working well, because this bug also brings portage down when it manifests. The reason is simple: portage is dependent on Python and Python is dependent on libstdc++. Suggested solution: Maintain some sort of "reference count" for each of the gcc configuration presented by the gcc-config command. When a package is merged, increase the reference count of the compiler used to build it. When a package is unmerged, decrease the reference count of its compiler. Don't delete any of those that have the reference count greater than zero or unmerge any packages used by such a configuration (unless user specifies a -f on commandline).
Which point of the the following warning did you miss? *** WARNING *** : DEPCLEAN CAN SERIOUSLY IMPAIR YOUR SYSTEM. USE CAUTION. *** WARNING *** : (Cancel: CONTROL-C) -- ALWAYS VERIFY ALL PACKAGES IN THE *** WARNING *** : CANDIDATE LIST FOR SANITY BEFORE ALLOWING DEPCLEAN TO *** WARNING *** : UNMERGE ANY PACKAGES. *** WARNING *** : *** WARNING *** : USE FLAGS MAY HAVE AN EXTREME EFFECT ON THE OUTPUT. *** WARNING *** : SOME LIBRARIES MAY BE USED BY PACKAGES BUT ARE NOT *** WARNING *** : CONSIDERED TO BE A DEPEND DUE TO USE FLAG SETTINGS. *** WARNING *** : emerge --update --deep --newuse world TO VERIFY *** WARNING *** : SANITY IN THIS REGARD. *** WARNING *** : *** WARNING *** : Packages in the list that are desired may be added *** WARNING *** : directly to the world file to cause them to be ignored *** WARNING *** : by depclean and maintained in the future. BREAKAGES DUE *** WARNING *** : TO UNMERGING AN ==IN-USE LIBRARY== MAY BE REPAIRED BY *** WARNING *** : MERGING *** THE PACKAGE THAT COMPLAINS *** ABOUT THE *** WARNING *** : MISSING LIBRARY.
Sorry, I didn't explain the issue very well. 1. Using "emerge --update --deep --newuse world" to increase sanity is not enough when unmerging one of the versions of gcc. Probably the only way to avoid these problems is to use "emerge --emptytree --update world" to force everything to be built with the new compiler before the old one is removed. 2. "BREAKAGES DUE TO UNMERGING AN ==IN-USE LIBRARY== MAY BE REPAIRED BY MERGING *** THE PACKAGE THAT COMPLAINS *** ABOUT THE MISSING LIBRARY." This is not possible when the package that complains about the library is Portage or Python 3. "DEPCLEAN CAN SERIOUSLY IMPAIR YOUR SYSTEM. USE CAUTION." The problem here is that it is not obvious that unmerging *any* version of gcc that was in use is not sane and can cause problems. This breakage occurs even when you don't modify USE in any way. 4. I just verified that the bug can wreak havoc even without the "emerge --depclean" command. Just merging a new version of GCC causes the old one to be unmerged. If not, probably "emerge --clean" should be sufficient to pull the bug on the light. 5. I do understand that putting my old compiler into `world' will make the system safe from these problems. But when I forget to do so, portage does not do this for me and problems may suddenly appear. 6. Now I realized that the libtool library files are being fixed when upgrading the GCC. There is still a problem with gcc-config, but that's a different bug (bug #95224). So closing ...
