[gentoo-dev] Re: GCC upgrades, FUD and gentoo documentation

[Duncan]

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