Ryan Hill posted on Mon, 10 Oct 2011 20:21:51 -0600 as excerpted: > There are some packages that all need to be built with the same version > of GCC. The whole qt-* family is an example, or at least it was a year > ago (I'm not using KDE any more). Luckily they tend to be bumped as a > unit. > > The biggest problem is building stuff with a newer version of gcc than > the "system" version, either outside of portage, or selectively changing > back with gcc-config. Programs can get linked to symbols in (usually) > libstdc++.so.6 that have a symbol version that doesn't exist in the > previous release. When you switch back to using that release as your > system compiler, > the libstc++ library also gets switched out, and suddenly your > gcc-4.6-compiled firefox won't launch. If you've ever gotten a bug > report like "libstdc++.so.6: version `GLIBCXX_3.4.15' not found" then > you've dealt with this. > > This isn't a problem most users encounter, but some do like to try to > rebuild some of their system a bit at a time, and this is the reason why > I usually recommend they rebuild everything. By making it an all or > nothing affair, they're less likely to try hopping back and forth > between versions.
As with you, this problem appears mostly with kde, here. But at least here, it's *NOT* because I'm TRYING to rebuild a bit of my system at a time, but because parts of it won't yet build with the new gcc. The problem generally occurs when I decided I've waited long enough for a long released upstream gcc (4.x.1 and often 4.x.2 are released already!) to get unmasked even to ~arch. Of course, having been thru this cycle a few times now, I well understand the reasons why it takes so long for Gentoo to bump gcc even to ~arch, and accept that I'll often have to dig thru bugs (often with patches attached for months, with no visible action, if I were to complain about Gentoo it'd be about the maintainers of those packages letting those bugs sit, or of packages that should be put up for someone else to maintain if the maintainers can no longer handle it, not about the efforts of the toolchain folks) and drop patches in /etc/portage/patches/* and/or overlay a package if the ebuild itself needs patched, and that a few packages might not yet have patches available. That's not the problem. The problem is often cmake related. Since cmake is C++, once I rebuild it against the new gcc, it tends to refuse to run if I switch to the old gcc. Which means I'm SOL for the cmake-based package in question if it can't yet be built against the new gcc, since the package itself won't build with new gcc, and cmake won't run to let the package build with the old gcc. Of course, there's often transient issues with various apps if I try to run them in the middle of the rebuild process, too, but they do tend to be just that, transient, and to go away once I've completed the full rebuild, even when it means manually finding patches (ok) or switching to older gcc (not as good, but usually works, except as mentioned with cmake based packages) occasionally to do it. Fortunately, kde upstream seems to be /relatively/ good about building with the latest gcc themselves, so there's not as many problems there as there certainly could be given the cmake issue, but it is usually a problem for the couple of corner-cases whose upstream devs apparently don't update gcc as fast as most of the rest of kde does (sometimes not kde-base/* but other kde-based packages), and/or for the occasional non- kde but still qt/cmake based app. Tho fortunately for me personally at least, while I continue using kde as my DE of choice, with the kdepim move to akonadi and my subsequent purge of anything kdepim based, and the time it seems to take to get serious konqueror/rekonq bugs fixed indicating that even most kde folks apparently default to firefox or other alternatives, such that I too now default to firefox, and with the kde4 amarok and kaffeine already long replaced with non-kde alternatives due to their breakage, and with USE=semantic-desktop now turned off since I killed akonadi and thus could actually do so, there's now rather less kde-based-apps to get broken, here, and what remains tends to run VASTLY better and faster without all that semantic-desktop crap dragging it down! =:^) So there's less opportunity for the problem to manifest here, than there once was. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
