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