1 |
On 14/02/06, Timo Veith <tv@×××××××××××.de> wrote: |
2 |
> Hi list readers, |
3 |
> |
4 |
> I have a server on which I haven't done the upgrade yet because I am |
5 |
> afraid of that potentially dangerous and long running procedure. |
6 |
> |
7 |
> What experiences do you have with upgrading gcc on production systems? |
8 |
|
9 |
I have done it. |
10 |
|
11 |
> Did everything went smoothly by following the upgrade howto [1]? |
12 |
|
13 |
Yes, I've kept one system alive through well over 2 years worth of |
14 |
upgrades (gcc and all). I actually upgraded to gcc-3.4 before a HOWTO |
15 |
existed. A lot of fuss has been made about the topic in general but |
16 |
really - once you cut through all the noise - it only boils down to |
17 |
two points: |
18 |
|
19 |
1) Make sure packages which are written (or partially written) in |
20 |
C++ are rebuilt (i.e. they should all link to libstdc++.so.6 |
21 |
afterwards, not libstdc++.so.5). |
22 |
|
23 |
2) It's also a good idea to rebuild your kernel/modules with the |
24 |
newer compiler. The reason is that your loadable kernel modules and |
25 |
the kernel image itself should be built with the same compiler (if you |
26 |
forget to ensure this is the case, you'll notice it when trying to |
27 |
build loadable kernel modules using ebuilds or if you try to augment |
28 |
an existing kernel with additional in-tree modules). |
29 |
|
30 |
There is no requirement to rebuild everything, just as there has never |
31 |
been with previous gcc versions. The aspect that makes the migration |
32 |
from gcc-3.3 -> gcc-3.4 so tricky is the libstdc++.so incompatibility. |
33 |
If you remove libstdc++.so.5 before any C++ binaries have been rebuilt |
34 |
then they'll break. This library is provided by *either* gcc-3.3 (and |
35 |
lower) OR the sys-libs/libstdc++-v3 package. That's why the HOWTO |
36 |
tells you to install libstdc++-v3 early. It makes the following kind |
37 |
of operation safe for example: |
38 |
|
39 |
# emerge libstdc++-v3 && emerge -C =gcc-3.3* |
40 |
|
41 |
Provided that the newer gcc version is selected and properly activated |
42 |
(with gcc-config) any C++ stuff that's rebuilt will link to |
43 |
libstdc++.so.6. It's important to attend to these packages if you have |
44 |
any because, whilst you can continue to run them in their present |
45 |
state so long as libstdc++.so.5 is provided, you can end up with |
46 |
compiliation/linking issues further down the line. So, I recommend |
47 |
actually taking a good look at listing 3.2 in the HOWTO and |
48 |
determining what's effected and attending to that *first*, even if you |
49 |
intend to rebuild everything in the long run. |
50 |
|
51 |
Once the C++ stuff has been dealt with there's actually no need for |
52 |
the older C++ runtime (on my system I actually never bothered |
53 |
installing libstdc++-v3 and placed a reference in |
54 |
/etc/portage/profiles/package.provided). I don't necessarily recommend |
55 |
this for anyone else because some folks use binary-only packages which |
56 |
implicitly link to libstdc++.so.5 and we have no option to recompile |
57 |
them although they are few and far between. |
58 |
|
59 |
With regards to my second point about the kernel, remember that the |
60 |
kernel is self-hosted and it's not mandatory to rebuild it. But let's |
61 |
say you have a kernel image currently executing which was built with |
62 |
gcc-3.3 but you then try to make modifications your existing source |
63 |
tree at /usr/src/linux and then (re)build it accordingly ... or that |
64 |
you try to emerge something that builds a loadable module against that |
65 |
tree. That's when it causes problems so what I would suggest is to |
66 |
make a backup of the "/usr/src/linux/.config" file then run "make |
67 |
mrproper" in the tree to clean it up. Then simply copy the config file |
68 |
back in and build over, given that gcc-3.4 is the active compiler and |
69 |
reboot with the rebuild kernel as and when it's convenient. |
70 |
|
71 |
Finally, I'd like to say that I've personally seen a LOT of people |
72 |
coming into #gentoo on IRC who have somehow managed to break python |
73 |
(which links to libstdc++.so) and thus cannot emerge anything. In view |
74 |
of how many people I have had to attend to in this regard, I would |
75 |
very strongly recommend to anyone who is about to upgrade to do one of |
76 |
the following two things prior: |
77 |
|
78 |
1) echo "dev-lang/python nocxx" >> /etc/portage/package.use && |
79 |
emerge --oneshot python (you can revert the flag and rebuild later if |
80 |
you want) |
81 |
|
82 |
2) echo "=dev-lang/python-2.4.2-r1" >> /etc/portage/package.keywords |
83 |
&& emerge --oneshot python (because this revision removes the |
84 |
pointless linkage to libstdc++.so) |
85 |
|
86 |
Either of those steps will render you immune to this particular |
87 |
problem. If you wish to return python to its previous "state" after |
88 |
the upgrade than that's obviously fine. |
89 |
|
90 |
HTH, |
91 |
|
92 |
--Kerin |
93 |
|
94 |
-- |
95 |
gentoo-server@g.o mailing list |