/[gentoo]/xml/htdocs/doc/en/gcc-upgrading.xml
Gentoo

Diff of /xml/htdocs/doc/en/gcc-upgrading.xml

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.30 Revision 1.31
1<?xml version='1.0' encoding="UTF-8"?> 1<?xml version='1.0' encoding="UTF-8"?>
2<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v 1.30 2011/09/04 17:53:40 swift Exp $ --> 2<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v 1.31 2011/10/13 15:11:55 swift Exp $ -->
3 3
4<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> 4<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
5 5
6<guide> 6<guide>
7<title>Gentoo GCC Upgrade Guide</title> 7<title>Gentoo GCC Upgrade Guide</title>
8 8
9<author title="Author"> 9<author title="Author">
10 <mail link="amne@gentoo.org">Wernfried Haas</mail>
11</author>
12<author title="Author">
13 <mail link="jkt@gentoo.org">Jan Kundrát</mail>
14</author>
15<author title="Editor">
16 <mail link="halcy0n"/>
17</author>
18<author title="Editor">
19 <mail link="nightmorph"/> 10 <mail link="swift"/>
20</author> 11</author>
21 12
22<abstract> 13<abstract>
23This document will guide the user through the process of upgrading GCC. 14This document will guide the user through the process of upgrading GCC.
24</abstract> 15</abstract>
25 16
26<!-- The content of this document is licensed under the CC-BY-SA license --> 17<!-- The content of this document is licensed under the CC-BY-SA license -->
27<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> 18<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
28<license/> 19<license/>
29 20
30<version>23</version> 21<version>24</version>
31<date>2008-07-19</date> 22<date>2011-10-13</date>
32 23
33<chapter id="intro"> 24<chapter id="quickstart">
25<title>Quickstart</title>
26<section>
34<title>Introduction</title> 27<title>Introduction</title>
28<body>
29
30<p>
31This is about <e>upgrading</e> GCC. Downgrading GCC might have unwanted side
32effects. Please refer to <uri link="#troubleshooting">Troubleshooting</uri> for
33some commonly reported issues.
34</p>
35
36<p>
37The next section gives a quick primer into GCC upgrades (and how easy they are).
38If you want to read the lengthy reasoning behind GCC upgrades, please continue
39with <uri link="#explanation">GCC Upgrading Explained</uri>.
40</p>
41
42</body>
35<section> 43</section>
36<title>GCC Upgrading</title>
37<body>
38
39<p>
40Why should you upgrade? Well, GCC is quite similar to any other package on your
41system, just a bit more critical. You should upgrade GCC whenever a new version
42fixes some bug that annoys you, new functionality you need is introduced, or if
43you want to keep your system up-to-date. If none of the previous cases apply to
44you, you can safely postpone upgrade as long as your GCC version is supported by
45Gentoo developers.
46</p>
47
48<p>
49If you install a new major version of GCC (such as 3.3.6 to 3.4.5), the system
50will not switch over to use it automatically. You'll have to explicitly request
51the change because the migration process might require some additional steps.
52If you decide not to switch, Portage will continue to use older version of your
53compiler until you change your mind, or remove the old compiler from the system.
54Non-major gcc upgrades are switched automatically for you (such as 3.4.5 to
553.4.6).
56</p>
57
58<p>
59This guide will document the necessary steps required to perform a seamless
60upgrade of the compiler used by your Gentoo box. A specific section is
61dedicated to the <uri link="#upgrade-3.3-to-3.4">upgrade from GCC 3.3 to
623.4</uri> and issues with <c>libstdc++</c>. A second specific
63section is for users <uri link="#first-install">first installing</uri> Gentoo
64using a stage3 tarball, after a new GCC major/minor version has been released.
65</p>
66
67<warn>
68It should be noted that upgrading from GCC-3.4 (or 3.3) to GCC-4.1 or greater
69still requires you to follow the <uri link="#upgrade-general">general upgrading
70instructions</uri>, as GCC-3.4 and GCC-4.1 use slightly different ABIs.
71</warn>
72
73</body>
74</section> 44<section>
75</chapter> 45<title>Short Version</title>
46<body>
76 47
77<chapter id="upgrade-general"> 48<p>
78<title>General Upgrade Instructions</title> 49If you are upgrading GCC then you do not need to do anything except switch
50compiler version and rebuild libtool:
51</p>
52
53<pre caption="Switching GCC version">
54# <i>emerge -u gcc</i>
55# <i>gcc-config -l</i>
56[1] i686-pc-linux-gnu-4.4.5 *
57[2] i686-pc-linux-gnu-4.5.3
58
59# <i>gcc-config 2</i>
60# <i>env-update &amp;&amp; source /etc/profile</i>
61# <i>emerge --oneshot libtool</i>
62</pre>
63
64<p>
65If you upgrade GCC from a version earlier than 3.4.0 (for the 3.x series) or
664.1, you will need to run <c>revdep-rebuild</c> as well:
67</p>
68
69<pre caption="Upgrading from a non-forward compatible GCC version">
70# <i>revdep-rebuild --library libstdc++.so.5</i>
71</pre>
72
73<p>
74There you go. Enjoy the new compiler!
75</p>
76
77</body>
78</section>
79</chapter>
80
81<chapter id="explanation">
82<title>GCC Upgrading Explained</title>
79<section> 83<section>
80<title>Introduction</title> 84<title>Introduction</title>
81<body> 85<body>
82 86
83<impo>
84If you're looking for instructions specific to upgrades from GCC-3.3 to GCC-3.4,
85please consult the <uri link="#upgrade-3.3-to-3.4">dedicated
86section</uri>.
87</impo>
88
89<impo>
90If you're looking for instructions specific to upgrades in GCC for new
91installs, please consult the <uri link="#first-install">dedicated
92section</uri>.
93</impo>
94
95<p>
96Generally speaking, upgrades to <e>bug fix releases</e>, like from 3.3.5 to
973.3.6, should be quite safe -- just emerge new version, switch your system to
98use it and rebuild the only affected package, <c>libtool</c>. However, some GCC
99upgrades break binary compatibility; in such cases a rebuild of the affected
100packages (or even whole toolchain and system) might be required.
101</p> 87<p>
102 88GCC upgrading has always been mystified, with suggestions ranging from "You do
89not need to do anything" up to "You will need to rebuild your entire system
90twice". Most of this FUD comes from the confusion surrounding ABI
91incompatibility. But first a quick pointer towards <c>libtool</c>.
103<p> 92</p>
104When we spoke about the need to switch your compiler to the newer version by
105hand, we said it won't happen automatically. However, there is one exception --
106upgrades to bug fix releases, like from 3.3.5 to 3.3.6 in case you don't use the
107"multislot" feature allowing them to coexist on one system. Multislot is
108disabled by default as the majority of users won't benefit from it.
109</p>
110 93
111<pre caption="Upgrading GCC">
112# <i>emerge -uav gcc</i>
113
114<comment>(Please substitute "i686-pc-linux-gnu-4.1.1" with the GCC
115version and CHOST settings you've upgraded to:)</comment>
116# <i>gcc-config i686-pc-linux-gnu-4.1.1</i>
117# <i>env-update &amp;&amp; source /etc/profile</i>
118
119<comment>If you upgraded from gcc 3 to 4 (e.g. from 3.4.6 to 4.1.1 in this
120example) you will have to run fix_libtool_files.sh manually</comment>
121<comment>(Replace $CHOST with your actual CHOST, found in /etc/make.conf)</comment>
122<comment>(Replace &lt;gcc-version&gt; with your new, updated GCC version)</comment>
123# <i>/usr/share/gcc-data/$CHOST/&lt;gcc-version&gt;/fix_libtool_files.sh 3.4.6</i>
124
125<comment>(Rebuilding libtool)</comment>
126# <i>emerge --oneshot -av libtool</i>
127</pre>
128
129<p>
130To be completely safe that your system is in a sane state, you <e>must</e>
131rebuild the toolchain and then world to make use of the new compiler.
132</p>
133
134<pre caption="Rebuilding system">
135# <i>emerge -eav system</i>
136# <i>emerge -eav world</i>
137</pre>
138
139<p>
140It is safe to remove the older GCC version at this time. If you feel the need,
141please issue the following command (as usual, substitute
142<c>=sys-devel/gcc-3.4*</c> with the version you want to uninstall):
143</p>
144
145<pre caption="Removing older GCC version">
146# <i>emerge -aC =sys-devel/gcc-3.4*</i>
147</pre>
148
149<impo>
150Please note that the GCC 4.1 and newer can compile only kernels newer than
1512.4.34. Don't remove your old GCC version if you want to use an older kernel.
152</impo>
153
154<impo> <!-- FIXME: do we really want to keep it here? -->
155In case you're upgrading from GCC-3.3, you should run <c>emerge --oneshot
156sys-libs/libstdc++-v3</c> to provide compatibility with older binary C++
157applications.
158</impo>
159
160</body> 94</body>
161</section>
162</chapter>
163
164<chapter id="upgrade-3.3-to-3.4">
165<title>Upgrading from GCC-3.3 to 3.4</title>
166<section> 95</section>
167<title>Introduction</title>
168<body>
169
170<p>
171The upgrade from GCC-3.3 to 3.4 is not seamless as the C++ ABI
172changed between these two versions. There is an issue with the <c>libstdc++</c>
173library which must be taken care of, as well.
174</p>
175
176</body>
177</section> 96<section>
178<section id="upgrade-3.3-to-3.4-choices"> 97<title>libtool and fix_libtool_files.sh</title>
179<title>The Choices</title>
180<body>
181
182<impo>
183If you upgrade from gcc 3.4 to 4.1, please consult the <uri
184link="#upgrade-general">General Update instructions</uri>.
185</impo>
186
187<impo>
188If you're upgrading on a SPARC machine, you will have to take the way of
189<uri link="#upgrade-3.3-to-3.4-emerge-e">complete system rebuild</uri> due to
190some internal <uri link="http://gcc.gnu.org/gcc-3.4/sparc-abi.html">ABI
191changes</uri> in GCC's parameter passing.
192</impo>
193
194<p>
195If you upgrade from gcc 3.3 to 3.4, you have two possibilities on how to
196upgrade your system. The <uri link="#upgrade-3.3-to-3.4-revdep-rebuild">first
197method</uri> is faster and requires use of the <c>revdep-rebuild</c> tool from
198package <c>gentoolkit</c> while the <uri
199link="#upgrade-3.3-to-3.4-emerge-e">second one</uri> rebuilds the entire
200system from scratch so it will make use of new GCC features. It's up to you to
201decide which of these two ways you will choose. In most cases, the first
202method is sufficient.
203</p>
204
205<p>
206If you upgrade from gcc 3.3 to 4.1, do not use the method based on
207revdep-rebuild, but do a <uri link="#upgrade-3.3-to-3.4-emerge-e">complete
208system rebuild</uri>.
209</p>
210
211</body> 98<body>
99
100<p>
101Earlier installments of GCC on Gentoo required you to run a specific command
102called <c>fix_libtool_files.sh</c>. Some time ago, the execution of this
103command has been integrated in the package deployments itself (through the
104toolchain eclass) so there is no need for users to call this themselves anymore.
105</p>
106
107<p>
108The reason we need to rebuild libtool after the upgrade of gcc
109versions is because of its main purpose: <e>libtool</e> is a toolset that
110aggregates platform-specific code in a generic interface, allowing applications
111to build against shared libraries without needing to deal with the platform
112specific aspects of shared libraries. To fulfill its function properly, the
113<c>libtool</c> script uses various library locations that have hardcoded GCC
114version information in them.
115</p>
116
117</body>
118</section>
212</section> 119<section>
213<section id="upgrade-3.3-to-3.4-revdep-rebuild"> 120<title>ABI Changes</title>
214<title>Using revdep-rebuild</title>
215<body> 121<body>
216 122
217<p>
218This method requires that you first install <c>gentoolkit</c> if you have not
219already done so. Then we will upgrade GCC and switch to the new compiler. We
220will also rebuild the <c>libtool</c> package to ensure that toolchain is in
221healthy state.
222</p> 123<p>
223 124An ABI, or <e>Application Binary Interface</e>, is a set of conventions used by
224<pre caption="Installing gentoolkit and upgrading GCC"> 125all tools that deal with binary representation of programs, including compilers,
225# <i>emerge -an gentoolkit</i> 126assemblers, linkers and language runtime support (source: <uri
226# <i>emerge -uav gcc</i> 127link="http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html">GCC Binary
227<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC 128Compatibility</uri>). When the ABI used for binary applications and libraries is
228version and CHOST settings you've upgraded to:)</comment> 129changed, you will risk getting linker errors or malfunctioning programs unless
229# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> 130you rebuild all libraries that use C++ code. Yes, C++, since most
230# <i>source /etc/profile</i> 131incompatibilities occur within the C++ ABI. This is also why we use the
231 132<c>revdep-rebuild</c> command against the <path>libstdc++.so.5</path> library.
232<comment>(Rebuilding libtool)</comment>
233# <i>emerge --oneshot -av libtool</i>
234</pre>
235
236<p> 133</p>
237Now, we want to see which packages that revdep-rebuild will want to rebuild.
238Then we will tell revdep-rebuild to actually rebuild the packages. This may take
239some time, so have some patience.
240</p>
241 134
242<pre caption="Using revdep-rebuild"> 135<pre caption="Rebuilding applications linked against libstdc++.so.5">
243# <i>revdep-rebuild --library libstdc++.so.5 -- -p -v</i>
244# <i>revdep-rebuild --library libstdc++.so.5</i> 136# <i>revdep-rebuild --library libstdc++.so.5</i>
245</pre> 137</pre>
246 138
247<note>
248It is possible that you might have problems with non-existing package versions
249due to them being outdated or masked. If this is the case, you will want to use
250the <c>--package-names</c> option to <c>revdep-rebuild</c>. This causes packages
251to be recompiled based on the package name, rather than the exact name and
252version.
253</note>
254
255<p>
256To provide compatibility with older binary C++ applications and any packages
257that revdep-rebuild might have missed, <c>sys-libs/libstdc++-v3</c> needs to be
258merged before you unmerge GCC 3.3 from your system.
259</p> 139<p>
260 140So why is this only needed up to GCC 3.4.0/4.1 ? That's because from that
261<pre caption="Installing libstdc++-v3 and cleaning up"> 141version onwards, GCC uses a forward compatible ABI, which removes the need for
262# <i>emerge --oneshot sys-libs/libstdc++-v3</i> 142rebuilding applications and libraries. Of course, guarantees can never be given
263# <i>emerge -aC =sys-devel/gcc-3.3*</i> 143indefinitely, but when an incompatibility occurs again, we'll definitely
144document it here ;-) In that case, the version of the <path>libstdc++.so</path>
145library will probably be increased.
264</pre> 146</p>
265 147
266</body>
267</section>
268<section id="upgrade-3.3-to-3.4-emerge-e">
269<title>Using emerge -e</title>
270<body> 148</body>
271
272<p>
273This method, while much slower, will rebuild your whole system to ensure that
274everything has been rebuilt with your new compiler, and therefore safer. At
275first, you will upgrade GCC and libtool and switch to your new compiler.
276</p>
277
278<pre caption="Upgrading GCC">
279# <i>emerge -uav gcc</i>
280<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC
281version and CHOST settings you've upgraded to:)</comment>
282# <i>gcc-config i686-pc-linux-gnu-3.4.5</i>
283# <i>source /etc/profile</i>
284
285<comment>If you upgraded from gcc 3 to 4 (e.g. from 3.3.6 to 4.1.1 in this
286example) you will have to run fix_libtool_files.sh manually</comment>
287<comment>(Replace $CHOST with your actual CHOST, found in /etc/make.conf)</comment>
288<comment>(Replace &lt;gcc-version&gt; with your new, updated GCC version)</comment>
289# <i>/usr/share/gcc-data/$CHOST/&lt;gcc-version&gt;/fix_libtool_files.sh 3.3.6</i>
290
291<comment>(Rebuilding libtool)</comment>
292# <i>emerge --oneshot -av libtool</i>
293</pre>
294
295<p>
296To provide compatibility with older binary C++ applications,
297<c>sys-libs/libstdc++-v3</c> needs to be merged onto your system.
298</p>
299
300<pre caption="Installing libstdc++-v3">
301# <i>emerge --oneshot sys-libs/libstdc++-v3</i>
302</pre>
303
304<p>
305Now we will go about first rebuilding the system target, then the world target.
306This will take a very long time, depending on the number of packages that you
307have installed, as it will rebuild your entire toolchain and supporting system
308files, followed by every package on your system, including the toolchain. This
309is necessary to ensure that all packages have been compiled with the new
310toolchain, including the toolchain itself.
311</p>
312
313<pre caption="Rebuilding system and world">
314# <i>emerge -e system</i>
315# <i>emerge -e world</i>
316</pre>
317
318<p>
319It is also safe to remove older GCC versions at this time:
320</p>
321
322<pre caption="Cleaning up">
323# <i>emerge -aC =sys-devel/gcc-3.3*</i>
324</pre>
325
326</body>
327</section>
328</chapter>
329
330<chapter id="first-install">
331<title>Upgrading to GCC on a First Install</title>
332<section> 149</section>
333<title>Introduction</title>
334<body>
335
336<p>
337A GCC upgrade on a system after installation from a stage3 tarball is a simple
338affair. One advantage users of new installations have is they do not have a
339plethora of software installed that links against the older version of GCC.
340The following example is for a GCC-3.3 to 3.4 upgrade. Certain parts
341will be different if upgrading from other versions of GCC. For example, the
342library names used for <c>revdep-rebuild</c> below are GCC 3.3 specific, as
343well as the need to install <c>libstdc++-v3</c>.
344</p>
345
346<p>
347If a user has not made any customizations to their system yet, then there are
348very few steps to get their system upgraded to a new GCC version. As with the
349GCC-3.3 to 3.4 upgrade, the user has a couple options. However, unlike the
350GCC-3.3 to 3.4 upgrade, this one is less complicated as there are fewer
351differences between the methods. The <uri
352link="#first-install-revdep-rebuild">first method</uri> is faster and makes use
353of the <c>revdep-rebuild</c> tool from <c>gentoolkit</c>, similar to the above
354procedure. Using revdep-rebuild causes only packages which actually link
355against GCC libraries to be rebuilt, while the <uri
356link="#first-install-emerge-e">second method</uri> causes your entire new
357install to be recompiled with the new GCC version and takes much longer. This
358second method is never required and only documented for completeness.
359</p>
360
361<p>
362These first steps are common between both methods, and should be completed by
363everyone.
364</p>
365
366<pre caption="Upgrading GCC">
367# <i>emerge -uav gcc</i>
368<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC
369version and CHOST settings you've upgraded to:)</comment>
370# <i>gcc-config i686-pc-linux-gnu-3.4.5</i>
371# <i>source /etc/profile</i>
372
373<comment>(Rebuilding libtool)</comment>
374# <i>emerge --oneshot -av libtool</i>
375</pre>
376
377<p>
378To provide compatibility with older binary C++ applications,
379<c>sys-libs/libstdc++-v3</c> needs to be merged onto your system.
380</p>
381
382<pre caption="Installing libstdc++-v3">
383# <i>emerge --oneshot sys-libs/libstdc++-v3</i>
384</pre>
385
386</body>
387</section> 150<section>
388 151<title>Rebuilding Everything</title>
389<section id="first-install-revdep-rebuild">
390<title>Using revdep-rebuild</title>
391<body>
392
393<p>
394This method requires that you first install <c>gentoolkit</c> if you have not
395already done so. We will then run <c>revdep-rebuild</c> to actually scan the
396installed packages for ones we need to rebuild, then rebuild them.
397</p>
398
399<pre caption="Installing gentoolkit and running revdep-rebuild">
400# <i>emerge -an gentoolkit</i>
401# <i>revdep-rebuild --library libstdc++.so.5 -- -p -v</i>
402# <i>revdep-rebuild --library libstdc++.so.5</i>
403</pre>
404
405<note>
406It is possible that you might have problems with non-existing package versions
407due to them being outdated or masked. If this is the case, you will want to use
408the <c>--package-names</c> option to <c>revdep-rebuild</c>. This causes packages
409to be recompiled based on the package name, rather than the exact name and
410version.
411</note>
412
413</body> 152<body>
414</section> 153
415<section id="first-install-emerge-e"> 154<p>
416<title>Using emerge -e</title> 155Some people swear that they need to rebuild every single package on their system
156when a new GCC version is made available. Of course, that doesn't make sense,
157since there are many applications that are not using GCC for their build and
158install process anyhow, so they would never be affected by such changes.
159</p>
160
161<p>
162That however doesn't mean they are completely incorrect: newer GCC versions
163often include better support for the processors' instruction set, which might
164influence the performance of some applications in a positive way. Although it is
165expected that this improvement is generally only marginally, in some cases
166(especially CPU intensive applications) this might yield notable improvements.
167</p>
168
169<p>
170There are also known cases where packages need to be built with the same
171compiler. Although these packages are usually bumped by Gentoo simultaneously
172(so that they are always built with the same GCC version) cherry-picking
173reinstalls on these packages might prove to be troublesome. The various
174<path>qt-*</path> packages are a nice example on this matter.
175</p>
176
417<body> 177</body>
418
419<p>
420This method, while much slower, will rebuild the system target to ensure that
421everything has been rebuilt with your new compiler. This is not necessary, but
422is valid if you are also making changes to CFLAGS or other make.conf variables
423that will affect the system compile.
424</p>
425
426<p>
427Since we are performing these actions after an initial installation, we do not
428need to recompile the <c>world</c> target as we would when doing an upgrade on
429an already installed system. However, you may choose to perform a world update
430in place of the system update, to ensure that all packages are updated.
431</p>
432
433<pre caption="Rebuilding system">
434# <i>emerge -e system</i>
435</pre>
436
437</body>
438</section>
439<section id="first-install-cleaning-up">
440<title>Cleaning up</title>
441<body>
442
443<p>
444It is also safe to remove older GCC versions at this time. Please substitute
445<c>YOUR-NEW-GCC-VERSION</c> with the actual version you've upgraded to:
446</p>
447
448<pre caption="Cleaning up">
449# <i>emerge -aC "&lt;sys-devel/gcc-YOUR-NEW-GCC-VERSION"</i>
450</pre>
451
452</body>
453</section>
454</chapter>
455
456<chapter id="common-pitfalls">
457<title>Common Pitfalls</title>
458<section> 178</section>
459<body> 179</chapter>
460 180
461<p> 181<chapter id="troubleshooting">
462It's important to disable <c>distcc</c> during upgrade. Mixing compiler versions 182<title>Troubleshooting</title>
463on your nodes <e>will</e> cause build issues. This is not required for ccache,
464as the cache objects will be invalidated anyway.
465</p>
466
467<p>
468Always use same GCC version for your kernel and additional kernel modules. Once
469you rebuild your world with new GCC, external modules (like
470<c>app-emulation/qemu-softmmu</c>) will fail to load. Please rebuild your
471kernel with the new GCC to fix that.
472</p>
473
474<p>
475If you're upgrading on a SPARC machine, make sure to rerun <c>silo -f</c> after
476re-emerging world to avoid possible issues.
477</p>
478
479</body>
480</section> 183<section>
184<title>libstdc++.so.6: version `GLIBCXX_3.4.15' not found</title>
185<body>
186
187<p>
188During updates, you might encounter an error like the following:
189</p>
190
191<pre caption="GLIBCXX_x.y.z not found">
192cmake_bootstrap_28021_test: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libstdc++.so.6:
193version `GLIBCXX_3.4.11' not found
194</pre>
195
196<p>
197This means that you are trying to build a package with an <e>older</e> GCC
198version than with which some depending libraries were built. Remember when we
199told that the C++ ABI if forward-compatible? That is true, but it ensures only
200that <e>higher</e> (or same) GCC versions can be used when building applications
201and linking libraries (compared to the GCC version used to build those
202libraries).
203</p>
204
205</body>
481<section> 206</section>
482<title>Frequent Error Messages</title> 207</chapter>
483<body>
484 208
485<p> 209<chapter>
486If your system complains about something like <e>libtool: link: 210<title>Resources</title>
487`/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool 211<section>
488archive</e>, please run 212<title>Gentoo Guides and Resources</title>
489<c>/usr/share/gcc-data/$CHOST/&lt;gcc-version&gt;/fix_libtool_files.sh 3.3.6</c> 213<body>
490(substitute "3.3.6" with the version numbers from the error message, and $CHOST
491and &lt;gcc-version&gt; with your actual CHOST and GCC version).
492</p>
493 214
494<p> 215<ul>
495If you see <e>error: /usr/bin/gcc-config: line 632: 216 <li>
496/etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory</e>, then try 217 <uri link="gcc-upgrading-upto-4.1.xml">GCC Upgrading up to 4.1</uri>,
497deleting <path>/etc/env.d/gcc/config-i686-pc-linux-gnu</path> and running 218 the previous version of this document
498<c>gcc-config</c> again, followed by <c>source /etc/profile</c>. Only do this 219 </li>
499if you do not have any cross-compilers set up, though. 220</ul>
500</p>
501
502<p>
503If a package fails during <c>emerge -e system</c> or <c>emerge -e world</c>,
504you can resume operation with <c>emerge --resume</c>. If a package fails
505repeatedly, skip it with <c>emerge --resume --skipfirst</c>. Don't run any
506other instances of emerge in between or you will lose the resume information.
507</p>
508
509<p>
510If you get an error message <e>spec failure: unrecognized spec option</e> while
511upgrading your compiler, try to switch back to your default compiler, unset the
512<c>GCC_SPECS</c> variable and upgrade GCC again:
513</p>
514
515<pre caption="Restoring primary specs">
516# <i>gcc-config 1</i>
517# <i>source /etc/profile</i>
518# <i>unset GCC_SPECS</i>
519# <i>emerge -uav gcc</i>
520</pre>
521 221
522</body> 222</body>
523</section> 223</section>
524</chapter> 224</chapter>
525</guide> 225</guide>

Legend:
Removed from v.1.30  
changed lines
  Added in v.1.31

  ViewVC Help
Powered by ViewVC 1.1.20