| 1 |
swift 11/10/13 15:11:55 |
| 2 |
|
| 3 |
Modified: gcc-upgrading.xml |
| 4 |
Added: gcc-upgrading-upto-4.1.xml |
| 5 |
Log: |
| 6 |
Updating GCC upgrading guide with comments and feedback from gentoo-dev@g.o. Fixes bugs #385069 and bug #384045 |
| 7 |
|
| 8 |
Revision Changes Path |
| 9 |
1.31 xml/htdocs/doc/en/gcc-upgrading.xml |
| 10 |
|
| 11 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml?rev=1.31&view=markup |
| 12 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml?rev=1.31&content-type=text/plain |
| 13 |
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml?r1=1.30&r2=1.31 |
| 14 |
|
| 15 |
Index: gcc-upgrading.xml |
| 16 |
=================================================================== |
| 17 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v |
| 18 |
retrieving revision 1.30 |
| 19 |
retrieving revision 1.31 |
| 20 |
diff -u -r1.30 -r1.31 |
| 21 |
--- gcc-upgrading.xml 4 Sep 2011 17:53:40 -0000 1.30 |
| 22 |
+++ gcc-upgrading.xml 13 Oct 2011 15:11:55 -0000 1.31 |
| 23 |
@@ -1,5 +1,5 @@ |
| 24 |
<?xml version='1.0' encoding="UTF-8"?> |
| 25 |
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v 1.30 2011/09/04 17:53:40 swift Exp $ --> |
| 26 |
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v 1.31 2011/10/13 15:11:55 swift Exp $ --> |
| 27 |
|
| 28 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 29 |
|
| 30 |
@@ -7,16 +7,7 @@ |
| 31 |
<title>Gentoo GCC Upgrade Guide</title> |
| 32 |
|
| 33 |
<author title="Author"> |
| 34 |
- <mail link="amne@g.o">Wernfried Haas</mail> |
| 35 |
-</author> |
| 36 |
-<author title="Author"> |
| 37 |
- <mail link="jkt@g.o">Jan Kundrát</mail> |
| 38 |
-</author> |
| 39 |
-<author title="Editor"> |
| 40 |
- <mail link="halcy0n"/> |
| 41 |
-</author> |
| 42 |
-<author title="Editor"> |
| 43 |
- <mail link="nightmorph"/> |
| 44 |
+ <mail link="swift"/> |
| 45 |
</author> |
| 46 |
|
| 47 |
<abstract> |
| 48 |
@@ -27,497 +18,206 @@ |
| 49 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 50 |
<license/> |
| 51 |
|
| 52 |
-<version>23</version> |
| 53 |
-<date>2008-07-19</date> |
| 54 |
+<version>24</version> |
| 55 |
+<date>2011-10-13</date> |
| 56 |
|
| 57 |
-<chapter id="intro"> |
| 58 |
-<title>Introduction</title> |
| 59 |
+<chapter id="quickstart"> |
| 60 |
+<title>Quickstart</title> |
| 61 |
<section> |
| 62 |
-<title>GCC Upgrading</title> |
| 63 |
+<title>Introduction</title> |
| 64 |
<body> |
| 65 |
|
| 66 |
<p> |
| 67 |
-Why should you upgrade? Well, GCC is quite similar to any other package on your |
| 68 |
-system, just a bit more critical. You should upgrade GCC whenever a new version |
| 69 |
-fixes some bug that annoys you, new functionality you need is introduced, or if |
| 70 |
-you want to keep your system up-to-date. If none of the previous cases apply to |
| 71 |
-you, you can safely postpone upgrade as long as your GCC version is supported by |
| 72 |
-Gentoo developers. |
| 73 |
+This is about <e>upgrading</e> GCC. Downgrading GCC might have unwanted side |
| 74 |
+effects. Please refer to <uri link="#troubleshooting">Troubleshooting</uri> for |
| 75 |
+some commonly reported issues. |
| 76 |
</p> |
| 77 |
|
| 78 |
<p> |
| 79 |
-If you install a new major version of GCC (such as 3.3.6 to 3.4.5), the system |
| 80 |
-will not switch over to use it automatically. You'll have to explicitly request |
| 81 |
-the change because the migration process might require some additional steps. |
| 82 |
-If you decide not to switch, Portage will continue to use older version of your |
| 83 |
-compiler until you change your mind, or remove the old compiler from the system. |
| 84 |
-Non-major gcc upgrades are switched automatically for you (such as 3.4.5 to |
| 85 |
-3.4.6). |
| 86 |
+The next section gives a quick primer into GCC upgrades (and how easy they are). |
| 87 |
+If you want to read the lengthy reasoning behind GCC upgrades, please continue |
| 88 |
+with <uri link="#explanation">GCC Upgrading Explained</uri>. |
| 89 |
</p> |
| 90 |
|
| 91 |
-<p> |
| 92 |
-This guide will document the necessary steps required to perform a seamless |
| 93 |
-upgrade of the compiler used by your Gentoo box. A specific section is |
| 94 |
-dedicated to the <uri link="#upgrade-3.3-to-3.4">upgrade from GCC 3.3 to |
| 95 |
-3.4</uri> and issues with <c>libstdc++</c>. A second specific |
| 96 |
-section is for users <uri link="#first-install">first installing</uri> Gentoo |
| 97 |
-using a stage3 tarball, after a new GCC major/minor version has been released. |
| 98 |
-</p> |
| 99 |
- |
| 100 |
-<warn> |
| 101 |
-It should be noted that upgrading from GCC-3.4 (or 3.3) to GCC-4.1 or greater |
| 102 |
-still requires you to follow the <uri link="#upgrade-general">general upgrading |
| 103 |
-instructions</uri>, as GCC-3.4 and GCC-4.1 use slightly different ABIs. |
| 104 |
-</warn> |
| 105 |
- |
| 106 |
</body> |
| 107 |
</section> |
| 108 |
-</chapter> |
| 109 |
- |
| 110 |
-<chapter id="upgrade-general"> |
| 111 |
-<title>General Upgrade Instructions</title> |
| 112 |
<section> |
| 113 |
-<title>Introduction</title> |
| 114 |
+<title>Short Version</title> |
| 115 |
<body> |
| 116 |
|
| 117 |
-<impo> |
| 118 |
-If you're looking for instructions specific to upgrades from GCC-3.3 to GCC-3.4, |
| 119 |
-please consult the <uri link="#upgrade-3.3-to-3.4">dedicated |
| 120 |
-section</uri>. |
| 121 |
-</impo> |
| 122 |
- |
| 123 |
-<impo> |
| 124 |
-If you're looking for instructions specific to upgrades in GCC for new |
| 125 |
-installs, please consult the <uri link="#first-install">dedicated |
| 126 |
-section</uri>. |
| 127 |
-</impo> |
| 128 |
- |
| 129 |
-<p> |
| 130 |
-Generally speaking, upgrades to <e>bug fix releases</e>, like from 3.3.5 to |
| 131 |
-3.3.6, should be quite safe -- just emerge new version, switch your system to |
| 132 |
-use it and rebuild the only affected package, <c>libtool</c>. However, some GCC |
| 133 |
-upgrades break binary compatibility; in such cases a rebuild of the affected |
| 134 |
-packages (or even whole toolchain and system) might be required. |
| 135 |
-</p> |
| 136 |
- |
| 137 |
<p> |
| 138 |
-When we spoke about the need to switch your compiler to the newer version by |
| 139 |
-hand, we said it won't happen automatically. However, there is one exception -- |
| 140 |
-upgrades to bug fix releases, like from 3.3.5 to 3.3.6 in case you don't use the |
| 141 |
-"multislot" feature allowing them to coexist on one system. Multislot is |
| 142 |
-disabled by default as the majority of users won't benefit from it. |
| 143 |
+If you are upgrading GCC then you do not need to do anything except switch |
| 144 |
+compiler version and rebuild libtool: |
| 145 |
</p> |
| 146 |
|
| 147 |
-<pre caption="Upgrading GCC"> |
| 148 |
-# <i>emerge -uav gcc</i> |
| 149 |
+<pre caption="Switching GCC version"> |
| 150 |
+# <i>emerge -u gcc</i> |
| 151 |
+# <i>gcc-config -l</i> |
| 152 |
+[1] i686-pc-linux-gnu-4.4.5 * |
| 153 |
+[2] i686-pc-linux-gnu-4.5.3 |
| 154 |
|
| 155 |
-<comment>(Please substitute "i686-pc-linux-gnu-4.1.1" with the GCC |
| 156 |
-version and CHOST settings you've upgraded to:)</comment> |
| 157 |
-# <i>gcc-config i686-pc-linux-gnu-4.1.1</i> |
| 158 |
+# <i>gcc-config 2</i> |
| 159 |
# <i>env-update && source /etc/profile</i> |
| 160 |
- |
| 161 |
-<comment>If you upgraded from gcc 3 to 4 (e.g. from 3.4.6 to 4.1.1 in this |
| 162 |
-example) you will have to run fix_libtool_files.sh manually</comment> |
| 163 |
-<comment>(Replace $CHOST with your actual CHOST, found in /etc/make.conf)</comment> |
| 164 |
-<comment>(Replace <gcc-version> with your new, updated GCC version)</comment> |
| 165 |
-# <i>/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.4.6</i> |
| 166 |
- |
| 167 |
-<comment>(Rebuilding libtool)</comment> |
| 168 |
-# <i>emerge --oneshot -av libtool</i> |
| 169 |
+# <i>emerge --oneshot libtool</i> |
| 170 |
</pre> |
| 171 |
|
| 172 |
<p> |
| 173 |
-To be completely safe that your system is in a sane state, you <e>must</e> |
| 174 |
-rebuild the toolchain and then world to make use of the new compiler. |
| 175 |
+If you upgrade GCC from a version earlier than 3.4.0 (for the 3.x series) or |
| 176 |
+4.1, you will need to run <c>revdep-rebuild</c> as well: |
| 177 |
</p> |
| 178 |
|
| 179 |
-<pre caption="Rebuilding system"> |
| 180 |
-# <i>emerge -eav system</i> |
| 181 |
-# <i>emerge -eav world</i> |
| 182 |
+<pre caption="Upgrading from a non-forward compatible GCC version"> |
| 183 |
+# <i>revdep-rebuild --library libstdc++.so.5</i> |
| 184 |
</pre> |
| 185 |
|
| 186 |
<p> |
| 187 |
-It is safe to remove the older GCC version at this time. If you feel the need, |
| 188 |
-please issue the following command (as usual, substitute |
| 189 |
-<c>=sys-devel/gcc-3.4*</c> with the version you want to uninstall): |
| 190 |
+There you go. Enjoy the new compiler! |
| 191 |
</p> |
| 192 |
|
| 193 |
-<pre caption="Removing older GCC version"> |
| 194 |
-# <i>emerge -aC =sys-devel/gcc-3.4*</i> |
| 195 |
-</pre> |
| 196 |
- |
| 197 |
-<impo> |
| 198 |
-Please note that the GCC 4.1 and newer can compile only kernels newer than |
| 199 |
-2.4.34. Don't remove your old GCC version if you want to use an older kernel. |
| 200 |
-</impo> |
| 201 |
- |
| 202 |
-<impo> <!-- FIXME: do we really want to keep it here? --> |
| 203 |
-In case you're upgrading from GCC-3.3, you should run <c>emerge --oneshot |
| 204 |
-sys-libs/libstdc++-v3</c> to provide compatibility with older binary C++ |
| 205 |
-applications. |
| 206 |
-</impo> |
| 207 |
- |
| 208 |
</body> |
| 209 |
</section> |
| 210 |
</chapter> |
| 211 |
|
| 212 |
-<chapter id="upgrade-3.3-to-3.4"> |
| 213 |
-<title>Upgrading from GCC-3.3 to 3.4</title> |
| 214 |
+<chapter id="explanation"> |
| 215 |
+<title>GCC Upgrading Explained</title> |
| 216 |
<section> |
| 217 |
<title>Introduction</title> |
| 218 |
<body> |
| 219 |
|
| 220 |
<p> |
| 221 |
-The upgrade from GCC-3.3 to 3.4 is not seamless as the C++ ABI |
| 222 |
-changed between these two versions. There is an issue with the <c>libstdc++</c> |
| 223 |
-library which must be taken care of, as well. |
| 224 |
+GCC upgrading has always been mystified, with suggestions ranging from "You do |
| 225 |
+not need to do anything" up to "You will need to rebuild your entire system |
| 226 |
+twice". Most of this FUD comes from the confusion surrounding ABI |
| 227 |
+incompatibility. But first a quick pointer towards <c>libtool</c>. |
| 228 |
</p> |
| 229 |
|
| 230 |
</body> |
| 231 |
</section> |
| 232 |
-<section id="upgrade-3.3-to-3.4-choices"> |
| 233 |
-<title>The Choices</title> |
| 234 |
+<section> |
| 235 |
+<title>libtool and fix_libtool_files.sh</title> |
| 236 |
<body> |
| 237 |
|
| 238 |
-<impo> |
| 239 |
-If you upgrade from gcc 3.4 to 4.1, please consult the <uri |
| 240 |
-link="#upgrade-general">General Update instructions</uri>. |
| 241 |
-</impo> |
| 242 |
- |
| 243 |
-<impo> |
| 244 |
-If you're upgrading on a SPARC machine, you will have to take the way of |
| 245 |
-<uri link="#upgrade-3.3-to-3.4-emerge-e">complete system rebuild</uri> due to |
| 246 |
-some internal <uri link="http://gcc.gnu.org/gcc-3.4/sparc-abi.html">ABI |
| 247 |
-changes</uri> in GCC's parameter passing. |
| 248 |
-</impo> |
| 249 |
- |
| 250 |
-<p> |
| 251 |
-If you upgrade from gcc 3.3 to 3.4, you have two possibilities on how to |
| 252 |
-upgrade your system. The <uri link="#upgrade-3.3-to-3.4-revdep-rebuild">first |
| 253 |
-method</uri> is faster and requires use of the <c>revdep-rebuild</c> tool from |
| 254 |
-package <c>gentoolkit</c> while the <uri |
| 255 |
-link="#upgrade-3.3-to-3.4-emerge-e">second one</uri> rebuilds the entire |
| 256 |
-system from scratch so it will make use of new GCC features. It's up to you to |
| 257 |
-decide which of these two ways you will choose. In most cases, the first |
| 258 |
-method is sufficient. |
| 259 |
-</p> |
| 260 |
- |
| 261 |
<p> |
| 262 |
-If you upgrade from gcc 3.3 to 4.1, do not use the method based on |
| 263 |
-revdep-rebuild, but do a <uri link="#upgrade-3.3-to-3.4-emerge-e">complete |
| 264 |
-system rebuild</uri>. |
| 265 |
+Earlier installments of GCC on Gentoo required you to run a specific command |
| 266 |
+called <c>fix_libtool_files.sh</c>. Some time ago, the execution of this |
| 267 |
+command has been integrated in the package deployments itself (through the |
| 268 |
+toolchain eclass) so there is no need for users to call this themselves anymore. |
| 269 |
</p> |
| 270 |
|
| 271 |
-</body> |
| 272 |
-</section> |
| 273 |
-<section id="upgrade-3.3-to-3.4-revdep-rebuild"> |
| 274 |
-<title>Using revdep-rebuild</title> |
| 275 |
-<body> |
| 276 |
- |
| 277 |
<p> |
| 278 |
-This method requires that you first install <c>gentoolkit</c> if you have not |
| 279 |
-already done so. Then we will upgrade GCC and switch to the new compiler. We |
| 280 |
-will also rebuild the <c>libtool</c> package to ensure that toolchain is in |
| 281 |
-healthy state. |
| 282 |
-</p> |
| 283 |
- |
| 284 |
-<pre caption="Installing gentoolkit and upgrading GCC"> |
| 285 |
-# <i>emerge -an gentoolkit</i> |
| 286 |
-# <i>emerge -uav gcc</i> |
| 287 |
-<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC |
| 288 |
-version and CHOST settings you've upgraded to:)</comment> |
| 289 |
-# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> |
| 290 |
-# <i>source /etc/profile</i> |
| 291 |
- |
| 292 |
-<comment>(Rebuilding libtool)</comment> |
| 293 |
-# <i>emerge --oneshot -av libtool</i> |
| 294 |
-</pre> |
| 295 |
- |
| 296 |
-<p> |
| 297 |
-Now, we want to see which packages that revdep-rebuild will want to rebuild. |
| 298 |
-Then we will tell revdep-rebuild to actually rebuild the packages. This may take |
| 299 |
-some time, so have some patience. |
| 300 |
+The reason we need to rebuild libtool after the upgrade of gcc |
| 301 |
+versions is because of its main purpose: <e>libtool</e> is a toolset that |
| 302 |
+aggregates platform-specific code in a generic interface, allowing applications |
| 303 |
+to build against shared libraries without needing to deal with the platform |
| 304 |
+specific aspects of shared libraries. To fulfill its function properly, the |
| 305 |
+<c>libtool</c> script uses various library locations that have hardcoded GCC |
| 306 |
+version information in them. |
| 307 |
</p> |
| 308 |
|
| 309 |
-<pre caption="Using revdep-rebuild"> |
| 310 |
-# <i>revdep-rebuild --library libstdc++.so.5 -- -p -v</i> |
| 311 |
-# <i>revdep-rebuild --library libstdc++.so.5</i> |
| 312 |
-</pre> |
| 313 |
- |
| 314 |
-<note> |
| 315 |
-It is possible that you might have problems with non-existing package versions |
| 316 |
-due to them being outdated or masked. If this is the case, you will want to use |
| 317 |
-the <c>--package-names</c> option to <c>revdep-rebuild</c>. This causes packages |
| 318 |
-to be recompiled based on the package name, rather than the exact name and |
| 319 |
-version. |
| 320 |
-</note> |
| 321 |
- |
| 322 |
-<p> |
| 323 |
-To provide compatibility with older binary C++ applications and any packages |
| 324 |
-that revdep-rebuild might have missed, <c>sys-libs/libstdc++-v3</c> needs to be |
| 325 |
-merged before you unmerge GCC 3.3 from your system. |
| 326 |
-</p> |
| 327 |
- |
| 328 |
-<pre caption="Installing libstdc++-v3 and cleaning up"> |
| 329 |
-# <i>emerge --oneshot sys-libs/libstdc++-v3</i> |
| 330 |
-# <i>emerge -aC =sys-devel/gcc-3.3*</i> |
| 331 |
-</pre> |
| 332 |
- |
| 333 |
</body> |
| 334 |
</section> |
| 335 |
-<section id="upgrade-3.3-to-3.4-emerge-e"> |
| 336 |
-<title>Using emerge -e</title> |
| 337 |
+<section> |
| 338 |
+<title>ABI Changes</title> |
| 339 |
<body> |
| 340 |
|
| 341 |
<p> |
| 342 |
-This method, while much slower, will rebuild your whole system to ensure that |
| 343 |
-everything has been rebuilt with your new compiler, and therefore safer. At |
| 344 |
-first, you will upgrade GCC and libtool and switch to your new compiler. |
| 345 |
-</p> |
| 346 |
- |
| 347 |
-<pre caption="Upgrading GCC"> |
| 348 |
-# <i>emerge -uav gcc</i> |
| 349 |
-<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC |
| 350 |
-version and CHOST settings you've upgraded to:)</comment> |
| 351 |
-# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> |
| 352 |
-# <i>source /etc/profile</i> |
| 353 |
- |
| 354 |
-<comment>If you upgraded from gcc 3 to 4 (e.g. from 3.3.6 to 4.1.1 in this |
| 355 |
-example) you will have to run fix_libtool_files.sh manually</comment> |
| 356 |
-<comment>(Replace $CHOST with your actual CHOST, found in /etc/make.conf)</comment> |
| 357 |
-<comment>(Replace <gcc-version> with your new, updated GCC version)</comment> |
| 358 |
-# <i>/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.3.6</i> |
| 359 |
- |
| 360 |
-<comment>(Rebuilding libtool)</comment> |
| 361 |
-# <i>emerge --oneshot -av libtool</i> |
| 362 |
-</pre> |
| 363 |
- |
| 364 |
-<p> |
| 365 |
-To provide compatibility with older binary C++ applications, |
| 366 |
-<c>sys-libs/libstdc++-v3</c> needs to be merged onto your system. |
| 367 |
+An ABI, or <e>Application Binary Interface</e>, is a set of conventions used by |
| 368 |
+all tools that deal with binary representation of programs, including compilers, |
| 369 |
+assemblers, linkers and language runtime support (source: <uri |
| 370 |
+link="http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html">GCC Binary |
| 371 |
+Compatibility</uri>). When the ABI used for binary applications and libraries is |
| 372 |
+changed, you will risk getting linker errors or malfunctioning programs unless |
| 373 |
+you rebuild all libraries that use C++ code. Yes, C++, since most |
| 374 |
+incompatibilities occur within the C++ ABI. This is also why we use the |
| 375 |
+<c>revdep-rebuild</c> command against the <path>libstdc++.so.5</path> library. |
| 376 |
</p> |
| 377 |
|
| 378 |
-<pre caption="Installing libstdc++-v3"> |
| 379 |
-# <i>emerge --oneshot sys-libs/libstdc++-v3</i> |
| 380 |
-</pre> |
| 381 |
- |
| 382 |
-<p> |
| 383 |
-Now we will go about first rebuilding the system target, then the world target. |
| 384 |
-This will take a very long time, depending on the number of packages that you |
| 385 |
-have installed, as it will rebuild your entire toolchain and supporting system |
| 386 |
-files, followed by every package on your system, including the toolchain. This |
| 387 |
-is necessary to ensure that all packages have been compiled with the new |
| 388 |
-toolchain, including the toolchain itself. |
| 389 |
-</p> |
| 390 |
- |
| 391 |
-<pre caption="Rebuilding system and world"> |
| 392 |
-# <i>emerge -e system</i> |
| 393 |
-# <i>emerge -e world</i> |
| 394 |
+<pre caption="Rebuilding applications linked against libstdc++.so.5"> |
| 395 |
+# <i>revdep-rebuild --library libstdc++.so.5</i> |
| 396 |
</pre> |
| 397 |
|
| 398 |
<p> |
| 399 |
-It is also safe to remove older GCC versions at this time: |
| 400 |
+So why is this only needed up to GCC 3.4.0/4.1 ? That's because from that |
| 401 |
+version onwards, GCC uses a forward compatible ABI, which removes the need for |
| 402 |
+rebuilding applications and libraries. Of course, guarantees can never be given |
| 403 |
+indefinitely, but when an incompatibility occurs again, we'll definitely |
| 404 |
+document it here ;-) In that case, the version of the <path>libstdc++.so</path> |
| 405 |
+library will probably be increased. |
| 406 |
</p> |
| 407 |
|
| 408 |
-<pre caption="Cleaning up"> |
| 409 |
-# <i>emerge -aC =sys-devel/gcc-3.3*</i> |
| 410 |
-</pre> |
| 411 |
- |
| 412 |
</body> |
| 413 |
</section> |
| 414 |
-</chapter> |
| 415 |
- |
| 416 |
-<chapter id="first-install"> |
| 417 |
-<title>Upgrading to GCC on a First Install</title> |
| 418 |
<section> |
| 419 |
-<title>Introduction</title> |
| 420 |
+<title>Rebuilding Everything</title> |
| 421 |
<body> |
| 422 |
|
| 423 |
<p> |
| 424 |
-A GCC upgrade on a system after installation from a stage3 tarball is a simple |
| 425 |
-affair. One advantage users of new installations have is they do not have a |
| 426 |
-plethora of software installed that links against the older version of GCC. |
| 427 |
-The following example is for a GCC-3.3 to 3.4 upgrade. Certain parts |
| 428 |
-will be different if upgrading from other versions of GCC. For example, the |
| 429 |
-library names used for <c>revdep-rebuild</c> below are GCC 3.3 specific, as |
| 430 |
-well as the need to install <c>libstdc++-v3</c>. |
| 431 |
+Some people swear that they need to rebuild every single package on their system |
| 432 |
+when a new GCC version is made available. Of course, that doesn't make sense, |
| 433 |
+since there are many applications that are not using GCC for their build and |
| 434 |
+install process anyhow, so they would never be affected by such changes. |
| 435 |
</p> |
| 436 |
|
| 437 |
<p> |
| 438 |
-If a user has not made any customizations to their system yet, then there are |
| 439 |
-very few steps to get their system upgraded to a new GCC version. As with the |
| 440 |
-GCC-3.3 to 3.4 upgrade, the user has a couple options. However, unlike the |
| 441 |
-GCC-3.3 to 3.4 upgrade, this one is less complicated as there are fewer |
| 442 |
-differences between the methods. The <uri |
| 443 |
-link="#first-install-revdep-rebuild">first method</uri> is faster and makes use |
| 444 |
-of the <c>revdep-rebuild</c> tool from <c>gentoolkit</c>, similar to the above |
| 445 |
-procedure. Using revdep-rebuild causes only packages which actually link |
| 446 |
-against GCC libraries to be rebuilt, while the <uri |
| 447 |
-link="#first-install-emerge-e">second method</uri> causes your entire new |
| 448 |
-install to be recompiled with the new GCC version and takes much longer. This |
| 449 |
-second method is never required and only documented for completeness. |
| 450 |
+That however doesn't mean they are completely incorrect: newer GCC versions |
| 451 |
+often include better support for the processors' instruction set, which might |
| 452 |
+influence the performance of some applications in a positive way. Although it is |
| 453 |
+expected that this improvement is generally only marginally, in some cases |
| 454 |
+(especially CPU intensive applications) this might yield notable improvements. |
| 455 |
</p> |
| 456 |
|
| 457 |
<p> |
| 458 |
-These first steps are common between both methods, and should be completed by |
| 459 |
-everyone. |
| 460 |
-</p> |
| 461 |
- |
| 462 |
-<pre caption="Upgrading GCC"> |
| 463 |
-# <i>emerge -uav gcc</i> |
| 464 |
-<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC |
| 465 |
-version and CHOST settings you've upgraded to:)</comment> |
| 466 |
-# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> |
| 467 |
-# <i>source /etc/profile</i> |
| 468 |
- |
| 469 |
-<comment>(Rebuilding libtool)</comment> |
| 470 |
-# <i>emerge --oneshot -av libtool</i> |
| 471 |
-</pre> |
| 472 |
- |
| 473 |
-<p> |
| 474 |
-To provide compatibility with older binary C++ applications, |
| 475 |
-<c>sys-libs/libstdc++-v3</c> needs to be merged onto your system. |
| 476 |
+There are also known cases where packages need to be built with the same |
| 477 |
+compiler. Although these packages are usually bumped by Gentoo simultaneously |
| 478 |
+(so that they are always built with the same GCC version) cherry-picking |
| 479 |
+reinstalls on these packages might prove to be troublesome. The various |
| 480 |
+<path>qt-*</path> packages are a nice example on this matter. |
| 481 |
</p> |
| 482 |
|
| 483 |
-<pre caption="Installing libstdc++-v3"> |
| 484 |
-# <i>emerge --oneshot sys-libs/libstdc++-v3</i> |
| 485 |
-</pre> |
| 486 |
- |
| 487 |
</body> |
| 488 |
</section> |
| 489 |
+</chapter> |
| 490 |
|
| 491 |
-<section id="first-install-revdep-rebuild"> |
| 492 |
-<title>Using revdep-rebuild</title> |
| 493 |
-<body> |
| 494 |
- |
| 495 |
-<p> |
| 496 |
-This method requires that you first install <c>gentoolkit</c> if you have not |
| 497 |
-already done so. We will then run <c>revdep-rebuild</c> to actually scan the |
| 498 |
-installed packages for ones we need to rebuild, then rebuild them. |
| 499 |
-</p> |
| 500 |
- |
| 501 |
-<pre caption="Installing gentoolkit and running revdep-rebuild"> |
| 502 |
-# <i>emerge -an gentoolkit</i> |
| 503 |
-# <i>revdep-rebuild --library libstdc++.so.5 -- -p -v</i> |
| 504 |
-# <i>revdep-rebuild --library libstdc++.so.5</i> |
| 505 |
-</pre> |
| 506 |
- |
| 507 |
-<note> |
| 508 |
-It is possible that you might have problems with non-existing package versions |
| 509 |
-due to them being outdated or masked. If this is the case, you will want to use |
| 510 |
-the <c>--package-names</c> option to <c>revdep-rebuild</c>. This causes packages |
| 511 |
-to be recompiled based on the package name, rather than the exact name and |
| 512 |
-version. |
| 513 |
-</note> |
| 514 |
- |
| 515 |
-</body> |
| 516 |
-</section> |
| 517 |
-<section id="first-install-emerge-e"> |
| 518 |
-<title>Using emerge -e</title> |
| 519 |
+<chapter id="troubleshooting"> |
| 520 |
+<title>Troubleshooting</title> |
| 521 |
+<section> |
| 522 |
+<title>libstdc++.so.6: version `GLIBCXX_3.4.15' not found</title> |
| 523 |
<body> |
| 524 |
|
| 525 |
<p> |
| 526 |
-This method, while much slower, will rebuild the system target to ensure that |
| 527 |
-everything has been rebuilt with your new compiler. This is not necessary, but |
| 528 |
-is valid if you are also making changes to CFLAGS or other make.conf variables |
| 529 |
-that will affect the system compile. |
| 530 |
-</p> |
| 531 |
- |
| 532 |
-<p> |
| 533 |
-Since we are performing these actions after an initial installation, we do not |
| 534 |
-need to recompile the <c>world</c> target as we would when doing an upgrade on |
| 535 |
-an already installed system. However, you may choose to perform a world update |
| 536 |
-in place of the system update, to ensure that all packages are updated. |
| 537 |
+During updates, you might encounter an error like the following: |
| 538 |
</p> |
| 539 |
|
| 540 |
-<pre caption="Rebuilding system"> |
| 541 |
-# <i>emerge -e system</i> |
| 542 |
+<pre caption="GLIBCXX_x.y.z not found"> |
| 543 |
+cmake_bootstrap_28021_test: /usr/lib/gcc/i486-pc-linux-gnu/4.1.2/libstdc++.so.6: |
| 544 |
+version `GLIBCXX_3.4.11' not found |
| 545 |
</pre> |
| 546 |
|
| 547 |
-</body> |
| 548 |
-</section> |
| 549 |
-<section id="first-install-cleaning-up"> |
| 550 |
-<title>Cleaning up</title> |
| 551 |
-<body> |
| 552 |
- |
| 553 |
<p> |
| 554 |
-It is also safe to remove older GCC versions at this time. Please substitute |
| 555 |
-<c>YOUR-NEW-GCC-VERSION</c> with the actual version you've upgraded to: |
| 556 |
+This means that you are trying to build a package with an <e>older</e> GCC |
| 557 |
+version than with which some depending libraries were built. Remember when we |
| 558 |
+told that the C++ ABI if forward-compatible? That is true, but it ensures only |
| 559 |
+that <e>higher</e> (or same) GCC versions can be used when building applications |
| 560 |
+and linking libraries (compared to the GCC version used to build those |
| 561 |
+libraries). |
| 562 |
</p> |
| 563 |
|
| 564 |
-<pre caption="Cleaning up"> |
| 565 |
-# <i>emerge -aC "<sys-devel/gcc-YOUR-NEW-GCC-VERSION"</i> |
| 566 |
-</pre> |
| 567 |
- |
| 568 |
</body> |
| 569 |
</section> |
| 570 |
</chapter> |
| 571 |
|
| 572 |
-<chapter id="common-pitfalls"> |
| 573 |
-<title>Common Pitfalls</title> |
| 574 |
+<chapter> |
| 575 |
+<title>Resources</title> |
| 576 |
<section> |
| 577 |
+<title>Gentoo Guides and Resources</title> |
| 578 |
<body> |
| 579 |
|
| 580 |
-<p> |
| 581 |
-It's important to disable <c>distcc</c> during upgrade. Mixing compiler versions |
| 582 |
-on your nodes <e>will</e> cause build issues. This is not required for ccache, |
| 583 |
-as the cache objects will be invalidated anyway. |
| 584 |
-</p> |
| 585 |
- |
| 586 |
-<p> |
| 587 |
-Always use same GCC version for your kernel and additional kernel modules. Once |
| 588 |
-you rebuild your world with new GCC, external modules (like |
| 589 |
-<c>app-emulation/qemu-softmmu</c>) will fail to load. Please rebuild your |
| 590 |
-kernel with the new GCC to fix that. |
| 591 |
-</p> |
| 592 |
- |
| 593 |
-<p> |
| 594 |
-If you're upgrading on a SPARC machine, make sure to rerun <c>silo -f</c> after |
| 595 |
-re-emerging world to avoid possible issues. |
| 596 |
-</p> |
| 597 |
- |
| 598 |
-</body> |
| 599 |
-</section> |
| 600 |
-<section> |
| 601 |
-<title>Frequent Error Messages</title> |
| 602 |
-<body> |
| 603 |
- |
| 604 |
-<p> |
| 605 |
-If your system complains about something like <e>libtool: link: |
| 606 |
-`/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool |
| 607 |
-archive</e>, please run |
| 608 |
-<c>/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.3.6</c> |
| 609 |
-(substitute "3.3.6" with the version numbers from the error message, and $CHOST |
| 610 |
-and <gcc-version> with your actual CHOST and GCC version). |
| 611 |
-</p> |
| 612 |
- |
| 613 |
-<p> |
| 614 |
-If you see <e>error: /usr/bin/gcc-config: line 632: |
| 615 |
-/etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory</e>, then try |
| 616 |
-deleting <path>/etc/env.d/gcc/config-i686-pc-linux-gnu</path> and running |
| 617 |
-<c>gcc-config</c> again, followed by <c>source /etc/profile</c>. Only do this |
| 618 |
-if you do not have any cross-compilers set up, though. |
| 619 |
-</p> |
| 620 |
- |
| 621 |
-<p> |
| 622 |
-If a package fails during <c>emerge -e system</c> or <c>emerge -e world</c>, |
| 623 |
-you can resume operation with <c>emerge --resume</c>. If a package fails |
| 624 |
-repeatedly, skip it with <c>emerge --resume --skipfirst</c>. Don't run any |
| 625 |
-other instances of emerge in between or you will lose the resume information. |
| 626 |
-</p> |
| 627 |
- |
| 628 |
-<p> |
| 629 |
-If you get an error message <e>spec failure: unrecognized spec option</e> while |
| 630 |
-upgrading your compiler, try to switch back to your default compiler, unset the |
| 631 |
-<c>GCC_SPECS</c> variable and upgrade GCC again: |
| 632 |
-</p> |
| 633 |
- |
| 634 |
-<pre caption="Restoring primary specs"> |
| 635 |
-# <i>gcc-config 1</i> |
| 636 |
-# <i>source /etc/profile</i> |
| 637 |
-# <i>unset GCC_SPECS</i> |
| 638 |
-# <i>emerge -uav gcc</i> |
| 639 |
-</pre> |
| 640 |
+<ul> |
| 641 |
+ <li> |
| 642 |
+ <uri link="gcc-upgrading-upto-4.1.xml">GCC Upgrading up to 4.1</uri>, |
| 643 |
+ the previous version of this document |
| 644 |
+ </li> |
| 645 |
+</ul> |
| 646 |
|
| 647 |
</body> |
| 648 |
</section> |
| 649 |
|
| 650 |
|
| 651 |
|
| 652 |
1.1 xml/htdocs/doc/en/gcc-upgrading-upto-4.1.xml |
| 653 |
|
| 654 |
file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/en/gcc-upgrading-upto-4.1.xml?rev=1.1&view=markup |
| 655 |
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/doc/en/gcc-upgrading-upto-4.1.xml?rev=1.1&content-type=text/plain |
| 656 |
|
| 657 |
Index: gcc-upgrading-upto-4.1.xml |
| 658 |
=================================================================== |
| 659 |
<?xml version='1.0' encoding="UTF-8"?> |
| 660 |
<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading-upto-4.1.xml,v 1.1 2011/10/13 15:11:55 swift Exp $ --> |
| 661 |
|
| 662 |
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd"> |
| 663 |
|
| 664 |
<guide> |
| 665 |
<title>Gentoo GCC Upgrade Guide for GCC Up To 4.1</title> |
| 666 |
|
| 667 |
<author title="Author"> |
| 668 |
<mail link="amne@g.o">Wernfried Haas</mail> |
| 669 |
</author> |
| 670 |
<author title="Author"> |
| 671 |
<mail link="jkt@g.o">Jan Kundrát</mail> |
| 672 |
</author> |
| 673 |
<author title="Editor"> |
| 674 |
<mail link="halcy0n"/> |
| 675 |
</author> |
| 676 |
<author title="Editor"> |
| 677 |
<mail link="nightmorph"/> |
| 678 |
</author> |
| 679 |
|
| 680 |
<abstract> |
| 681 |
This document will guide the user through the process of upgrading GCC. |
| 682 |
</abstract> |
| 683 |
|
| 684 |
<!-- The content of this document is licensed under the CC-BY-SA license --> |
| 685 |
<!-- See http://creativecommons.org/licenses/by-sa/2.5 --> |
| 686 |
<license/> |
| 687 |
|
| 688 |
<version>23</version> |
| 689 |
<date>2008-07-19</date> |
| 690 |
|
| 691 |
<chapter id="intro"> |
| 692 |
<title>Introduction</title> |
| 693 |
<section> |
| 694 |
<title>GCC Upgrading</title> |
| 695 |
<body> |
| 696 |
|
| 697 |
<p> |
| 698 |
Why should you upgrade? Well, GCC is quite similar to any other package on your |
| 699 |
system, just a bit more critical. You should upgrade GCC whenever a new version |
| 700 |
fixes some bug that annoys you, new functionality you need is introduced, or if |
| 701 |
you want to keep your system up-to-date. If none of the previous cases apply to |
| 702 |
you, you can safely postpone upgrade as long as your GCC version is supported by |
| 703 |
Gentoo developers. |
| 704 |
</p> |
| 705 |
|
| 706 |
<p> |
| 707 |
If you install a new major version of GCC (such as 3.3.6 to 3.4.5), the system |
| 708 |
will not switch over to use it automatically. You'll have to explicitly request |
| 709 |
the change because the migration process might require some additional steps. |
| 710 |
If you decide not to switch, Portage will continue to use older version of your |
| 711 |
compiler until you change your mind, or remove the old compiler from the system. |
| 712 |
Non-major gcc upgrades are switched automatically for you (such as 3.4.5 to |
| 713 |
3.4.6). |
| 714 |
</p> |
| 715 |
|
| 716 |
<p> |
| 717 |
This guide will document the necessary steps required to perform a seamless |
| 718 |
upgrade of the compiler used by your Gentoo box. A specific section is |
| 719 |
dedicated to the <uri link="#upgrade-3.3-to-3.4">upgrade from GCC 3.3 to |
| 720 |
3.4</uri> and issues with <c>libstdc++</c>. A second specific |
| 721 |
section is for users <uri link="#first-install">first installing</uri> Gentoo |
| 722 |
using a stage3 tarball, after a new GCC major/minor version has been released. |
| 723 |
</p> |
| 724 |
|
| 725 |
<warn> |
| 726 |
It should be noted that upgrading from GCC-3.4 (or 3.3) to GCC-4.1 or greater |
| 727 |
still requires you to follow the <uri link="#upgrade-general">general upgrading |
| 728 |
instructions</uri>, as GCC-3.4 and GCC-4.1 use slightly different ABIs. |
| 729 |
</warn> |
| 730 |
|
| 731 |
</body> |
| 732 |
</section> |
| 733 |
</chapter> |
| 734 |
|
| 735 |
<chapter id="upgrade-general"> |
| 736 |
<title>General Upgrade Instructions</title> |
| 737 |
<section> |
| 738 |
<title>Introduction</title> |
| 739 |
<body> |
| 740 |
|
| 741 |
<impo> |
| 742 |
If you're looking for instructions specific to upgrades from GCC-3.3 to GCC-3.4, |
| 743 |
please consult the <uri link="#upgrade-3.3-to-3.4">dedicated |
| 744 |
section</uri>. |
| 745 |
</impo> |
| 746 |
|
| 747 |
<impo> |
| 748 |
If you're looking for instructions specific to upgrades in GCC for new |
| 749 |
installs, please consult the <uri link="#first-install">dedicated |
| 750 |
section</uri>. |
| 751 |
</impo> |
| 752 |
|
| 753 |
<p> |
| 754 |
Generally speaking, upgrades to <e>bug fix releases</e>, like from 3.3.5 to |
| 755 |
3.3.6, should be quite safe -- just emerge new version, switch your system to |
| 756 |
use it and rebuild the only affected package, <c>libtool</c>. However, some GCC |
| 757 |
upgrades break binary compatibility; in such cases a rebuild of the affected |
| 758 |
packages (or even whole toolchain and system) might be required. |
| 759 |
</p> |
| 760 |
|
| 761 |
<p> |
| 762 |
When we spoke about the need to switch your compiler to the newer version by |
| 763 |
hand, we said it won't happen automatically. However, there is one exception -- |
| 764 |
upgrades to bug fix releases, like from 3.3.5 to 3.3.6 in case you don't use the |
| 765 |
"multislot" feature allowing them to coexist on one system. Multislot is |
| 766 |
disabled by default as the majority of users won't benefit from it. |
| 767 |
</p> |
| 768 |
|
| 769 |
<pre caption="Upgrading GCC"> |
| 770 |
# <i>emerge -uav gcc</i> |
| 771 |
|
| 772 |
<comment>(Please substitute "i686-pc-linux-gnu-4.1.1" with the GCC |
| 773 |
version and CHOST settings you've upgraded to:)</comment> |
| 774 |
# <i>gcc-config i686-pc-linux-gnu-4.1.1</i> |
| 775 |
# <i>env-update && source /etc/profile</i> |
| 776 |
|
| 777 |
<comment>If you upgraded from gcc 3 to 4 (e.g. from 3.4.6 to 4.1.1 in this |
| 778 |
example) you will have to run fix_libtool_files.sh manually</comment> |
| 779 |
<comment>(Replace $CHOST with your actual CHOST, found in /etc/make.conf)</comment> |
| 780 |
<comment>(Replace <gcc-version> with your new, updated GCC version)</comment> |
| 781 |
# <i>/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.4.6</i> |
| 782 |
|
| 783 |
<comment>(Rebuilding libtool)</comment> |
| 784 |
# <i>emerge --oneshot -av libtool</i> |
| 785 |
</pre> |
| 786 |
|
| 787 |
<p> |
| 788 |
To be completely safe that your system is in a sane state, you <e>must</e> |
| 789 |
rebuild the toolchain and then world to make use of the new compiler. |
| 790 |
</p> |
| 791 |
|
| 792 |
<pre caption="Rebuilding system"> |
| 793 |
# <i>emerge -eav system</i> |
| 794 |
# <i>emerge -eav world</i> |
| 795 |
</pre> |
| 796 |
|
| 797 |
<p> |
| 798 |
It is safe to remove the older GCC version at this time. If you feel the need, |
| 799 |
please issue the following command (as usual, substitute |
| 800 |
<c>=sys-devel/gcc-3.4*</c> with the version you want to uninstall): |
| 801 |
</p> |
| 802 |
|
| 803 |
<pre caption="Removing older GCC version"> |
| 804 |
# <i>emerge -aC =sys-devel/gcc-3.4*</i> |
| 805 |
</pre> |
| 806 |
|
| 807 |
<impo> |
| 808 |
Please note that the GCC 4.1 and newer can compile only kernels newer than |
| 809 |
2.4.34. Don't remove your old GCC version if you want to use an older kernel. |
| 810 |
</impo> |
| 811 |
|
| 812 |
<impo> <!-- FIXME: do we really want to keep it here? --> |
| 813 |
In case you're upgrading from GCC-3.3, you should run <c>emerge --oneshot |
| 814 |
sys-libs/libstdc++-v3</c> to provide compatibility with older binary C++ |
| 815 |
applications. |
| 816 |
</impo> |
| 817 |
|
| 818 |
</body> |
| 819 |
</section> |
| 820 |
</chapter> |
| 821 |
|
| 822 |
<chapter id="upgrade-3.3-to-3.4"> |
| 823 |
<title>Upgrading from GCC-3.3 to 3.4</title> |
| 824 |
<section> |
| 825 |
<title>Introduction</title> |
| 826 |
<body> |
| 827 |
|
| 828 |
<p> |
| 829 |
The upgrade from GCC-3.3 to 3.4 is not seamless as the C++ ABI |
| 830 |
changed between these two versions. There is an issue with the <c>libstdc++</c> |
| 831 |
library which must be taken care of, as well. |
| 832 |
</p> |
| 833 |
|
| 834 |
</body> |
| 835 |
</section> |
| 836 |
<section id="upgrade-3.3-to-3.4-choices"> |
| 837 |
<title>The Choices</title> |
| 838 |
<body> |
| 839 |
|
| 840 |
<impo> |
| 841 |
If you upgrade from gcc 3.4 to 4.1, please consult the <uri |
| 842 |
link="#upgrade-general">General Update instructions</uri>. |
| 843 |
</impo> |
| 844 |
|
| 845 |
<impo> |
| 846 |
If you're upgrading on a SPARC machine, you will have to take the way of |
| 847 |
<uri link="#upgrade-3.3-to-3.4-emerge-e">complete system rebuild</uri> due to |
| 848 |
some internal <uri link="http://gcc.gnu.org/gcc-3.4/sparc-abi.html">ABI |
| 849 |
changes</uri> in GCC's parameter passing. |
| 850 |
</impo> |
| 851 |
|
| 852 |
<p> |
| 853 |
If you upgrade from gcc 3.3 to 3.4, you have two possibilities on how to |
| 854 |
upgrade your system. The <uri link="#upgrade-3.3-to-3.4-revdep-rebuild">first |
| 855 |
method</uri> is faster and requires use of the <c>revdep-rebuild</c> tool from |
| 856 |
package <c>gentoolkit</c> while the <uri |
| 857 |
link="#upgrade-3.3-to-3.4-emerge-e">second one</uri> rebuilds the entire |
| 858 |
system from scratch so it will make use of new GCC features. It's up to you to |
| 859 |
decide which of these two ways you will choose. In most cases, the first |
| 860 |
method is sufficient. |
| 861 |
</p> |
| 862 |
|
| 863 |
<p> |
| 864 |
If you upgrade from gcc 3.3 to 4.1, do not use the method based on |
| 865 |
revdep-rebuild, but do a <uri link="#upgrade-3.3-to-3.4-emerge-e">complete |
| 866 |
system rebuild</uri>. |
| 867 |
</p> |
| 868 |
|
| 869 |
</body> |
| 870 |
</section> |
| 871 |
<section id="upgrade-3.3-to-3.4-revdep-rebuild"> |
| 872 |
<title>Using revdep-rebuild</title> |
| 873 |
<body> |
| 874 |
|
| 875 |
<p> |
| 876 |
This method requires that you first install <c>gentoolkit</c> if you have not |
| 877 |
already done so. Then we will upgrade GCC and switch to the new compiler. We |
| 878 |
will also rebuild the <c>libtool</c> package to ensure that toolchain is in |
| 879 |
healthy state. |
| 880 |
</p> |
| 881 |
|
| 882 |
<pre caption="Installing gentoolkit and upgrading GCC"> |
| 883 |
# <i>emerge -an gentoolkit</i> |
| 884 |
# <i>emerge -uav gcc</i> |
| 885 |
<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC |
| 886 |
version and CHOST settings you've upgraded to:)</comment> |
| 887 |
# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> |
| 888 |
# <i>source /etc/profile</i> |
| 889 |
|
| 890 |
<comment>(Rebuilding libtool)</comment> |
| 891 |
# <i>emerge --oneshot -av libtool</i> |
| 892 |
</pre> |
| 893 |
|
| 894 |
<p> |
| 895 |
Now, we want to see which packages that revdep-rebuild will want to rebuild. |
| 896 |
Then we will tell revdep-rebuild to actually rebuild the packages. This may take |
| 897 |
some time, so have some patience. |
| 898 |
</p> |
| 899 |
|
| 900 |
<pre caption="Using revdep-rebuild"> |
| 901 |
# <i>revdep-rebuild --library libstdc++.so.5 -- -p -v</i> |
| 902 |
# <i>revdep-rebuild --library libstdc++.so.5</i> |
| 903 |
</pre> |
| 904 |
|
| 905 |
<note> |
| 906 |
It is possible that you might have problems with non-existing package versions |
| 907 |
due to them being outdated or masked. If this is the case, you will want to use |
| 908 |
the <c>--package-names</c> option to <c>revdep-rebuild</c>. This causes packages |
| 909 |
to be recompiled based on the package name, rather than the exact name and |
| 910 |
version. |
| 911 |
</note> |
| 912 |
|
| 913 |
<p> |
| 914 |
To provide compatibility with older binary C++ applications and any packages |
| 915 |
that revdep-rebuild might have missed, <c>sys-libs/libstdc++-v3</c> needs to be |
| 916 |
merged before you unmerge GCC 3.3 from your system. |
| 917 |
</p> |
| 918 |
|
| 919 |
<pre caption="Installing libstdc++-v3 and cleaning up"> |
| 920 |
# <i>emerge --oneshot sys-libs/libstdc++-v3</i> |
| 921 |
# <i>emerge -aC =sys-devel/gcc-3.3*</i> |
| 922 |
</pre> |
| 923 |
|
| 924 |
</body> |
| 925 |
</section> |
| 926 |
<section id="upgrade-3.3-to-3.4-emerge-e"> |
| 927 |
<title>Using emerge -e</title> |
| 928 |
<body> |
| 929 |
|
| 930 |
<p> |
| 931 |
This method, while much slower, will rebuild your whole system to ensure that |
| 932 |
everything has been rebuilt with your new compiler, and therefore safer. At |
| 933 |
first, you will upgrade GCC and libtool and switch to your new compiler. |
| 934 |
</p> |
| 935 |
|
| 936 |
<pre caption="Upgrading GCC"> |
| 937 |
# <i>emerge -uav gcc</i> |
| 938 |
<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC |
| 939 |
version and CHOST settings you've upgraded to:)</comment> |
| 940 |
# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> |
| 941 |
# <i>source /etc/profile</i> |
| 942 |
|
| 943 |
<comment>If you upgraded from gcc 3 to 4 (e.g. from 3.3.6 to 4.1.1 in this |
| 944 |
example) you will have to run fix_libtool_files.sh manually</comment> |
| 945 |
<comment>(Replace $CHOST with your actual CHOST, found in /etc/make.conf)</comment> |
| 946 |
<comment>(Replace <gcc-version> with your new, updated GCC version)</comment> |
| 947 |
# <i>/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.3.6</i> |
| 948 |
|
| 949 |
<comment>(Rebuilding libtool)</comment> |
| 950 |
# <i>emerge --oneshot -av libtool</i> |
| 951 |
</pre> |
| 952 |
|
| 953 |
<p> |
| 954 |
To provide compatibility with older binary C++ applications, |
| 955 |
<c>sys-libs/libstdc++-v3</c> needs to be merged onto your system. |
| 956 |
</p> |
| 957 |
|
| 958 |
<pre caption="Installing libstdc++-v3"> |
| 959 |
# <i>emerge --oneshot sys-libs/libstdc++-v3</i> |
| 960 |
</pre> |
| 961 |
|
| 962 |
<p> |
| 963 |
Now we will go about first rebuilding the system target, then the world target. |
| 964 |
This will take a very long time, depending on the number of packages that you |
| 965 |
have installed, as it will rebuild your entire toolchain and supporting system |
| 966 |
files, followed by every package on your system, including the toolchain. This |
| 967 |
is necessary to ensure that all packages have been compiled with the new |
| 968 |
toolchain, including the toolchain itself. |
| 969 |
</p> |
| 970 |
|
| 971 |
<pre caption="Rebuilding system and world"> |
| 972 |
# <i>emerge -e system</i> |
| 973 |
# <i>emerge -e world</i> |
| 974 |
</pre> |
| 975 |
|
| 976 |
<p> |
| 977 |
It is also safe to remove older GCC versions at this time: |
| 978 |
</p> |
| 979 |
|
| 980 |
<pre caption="Cleaning up"> |
| 981 |
# <i>emerge -aC =sys-devel/gcc-3.3*</i> |
| 982 |
</pre> |
| 983 |
|
| 984 |
</body> |
| 985 |
</section> |
| 986 |
</chapter> |
| 987 |
|
| 988 |
<chapter id="first-install"> |
| 989 |
<title>Upgrading to GCC on a First Install</title> |
| 990 |
<section> |
| 991 |
<title>Introduction</title> |
| 992 |
<body> |
| 993 |
|
| 994 |
<p> |
| 995 |
A GCC upgrade on a system after installation from a stage3 tarball is a simple |
| 996 |
affair. One advantage users of new installations have is they do not have a |
| 997 |
plethora of software installed that links against the older version of GCC. |
| 998 |
The following example is for a GCC-3.3 to 3.4 upgrade. Certain parts |
| 999 |
will be different if upgrading from other versions of GCC. For example, the |
| 1000 |
library names used for <c>revdep-rebuild</c> below are GCC 3.3 specific, as |
| 1001 |
well as the need to install <c>libstdc++-v3</c>. |
| 1002 |
</p> |
| 1003 |
|
| 1004 |
<p> |
| 1005 |
If a user has not made any customizations to their system yet, then there are |
| 1006 |
very few steps to get their system upgraded to a new GCC version. As with the |
| 1007 |
GCC-3.3 to 3.4 upgrade, the user has a couple options. However, unlike the |
| 1008 |
GCC-3.3 to 3.4 upgrade, this one is less complicated as there are fewer |
| 1009 |
differences between the methods. The <uri |
| 1010 |
link="#first-install-revdep-rebuild">first method</uri> is faster and makes use |
| 1011 |
of the <c>revdep-rebuild</c> tool from <c>gentoolkit</c>, similar to the above |
| 1012 |
procedure. Using revdep-rebuild causes only packages which actually link |
| 1013 |
against GCC libraries to be rebuilt, while the <uri |
| 1014 |
link="#first-install-emerge-e">second method</uri> causes your entire new |
| 1015 |
install to be recompiled with the new GCC version and takes much longer. This |
| 1016 |
second method is never required and only documented for completeness. |
| 1017 |
</p> |
| 1018 |
|
| 1019 |
<p> |
| 1020 |
These first steps are common between both methods, and should be completed by |
| 1021 |
everyone. |
| 1022 |
</p> |
| 1023 |
|
| 1024 |
<pre caption="Upgrading GCC"> |
| 1025 |
# <i>emerge -uav gcc</i> |
| 1026 |
<comment>(Please substitute "i686-pc-linux-gnu-3.4.5" with the GCC |
| 1027 |
version and CHOST settings you've upgraded to:)</comment> |
| 1028 |
# <i>gcc-config i686-pc-linux-gnu-3.4.5</i> |
| 1029 |
# <i>source /etc/profile</i> |
| 1030 |
|
| 1031 |
<comment>(Rebuilding libtool)</comment> |
| 1032 |
# <i>emerge --oneshot -av libtool</i> |
| 1033 |
</pre> |
| 1034 |
|
| 1035 |
<p> |
| 1036 |
To provide compatibility with older binary C++ applications, |
| 1037 |
<c>sys-libs/libstdc++-v3</c> needs to be merged onto your system. |
| 1038 |
</p> |
| 1039 |
|
| 1040 |
<pre caption="Installing libstdc++-v3"> |
| 1041 |
# <i>emerge --oneshot sys-libs/libstdc++-v3</i> |
| 1042 |
</pre> |
| 1043 |
|
| 1044 |
</body> |
| 1045 |
</section> |
| 1046 |
|
| 1047 |
<section id="first-install-revdep-rebuild"> |
| 1048 |
<title>Using revdep-rebuild</title> |
| 1049 |
<body> |
| 1050 |
|
| 1051 |
<p> |
| 1052 |
This method requires that you first install <c>gentoolkit</c> if you have not |
| 1053 |
already done so. We will then run <c>revdep-rebuild</c> to actually scan the |
| 1054 |
installed packages for ones we need to rebuild, then rebuild them. |
| 1055 |
</p> |
| 1056 |
|
| 1057 |
<pre caption="Installing gentoolkit and running revdep-rebuild"> |
| 1058 |
# <i>emerge -an gentoolkit</i> |
| 1059 |
# <i>revdep-rebuild --library libstdc++.so.5 -- -p -v</i> |
| 1060 |
# <i>revdep-rebuild --library libstdc++.so.5</i> |
| 1061 |
</pre> |
| 1062 |
|
| 1063 |
<note> |
| 1064 |
It is possible that you might have problems with non-existing package versions |
| 1065 |
due to them being outdated or masked. If this is the case, you will want to use |
| 1066 |
the <c>--package-names</c> option to <c>revdep-rebuild</c>. This causes packages |
| 1067 |
to be recompiled based on the package name, rather than the exact name and |
| 1068 |
version. |
| 1069 |
</note> |
| 1070 |
|
| 1071 |
</body> |
| 1072 |
</section> |
| 1073 |
<section id="first-install-emerge-e"> |
| 1074 |
<title>Using emerge -e</title> |
| 1075 |
<body> |
| 1076 |
|
| 1077 |
<p> |
| 1078 |
This method, while much slower, will rebuild the system target to ensure that |
| 1079 |
everything has been rebuilt with your new compiler. This is not necessary, but |
| 1080 |
is valid if you are also making changes to CFLAGS or other make.conf variables |
| 1081 |
that will affect the system compile. |
| 1082 |
</p> |
| 1083 |
|
| 1084 |
<p> |
| 1085 |
Since we are performing these actions after an initial installation, we do not |
| 1086 |
need to recompile the <c>world</c> target as we would when doing an upgrade on |
| 1087 |
an already installed system. However, you may choose to perform a world update |
| 1088 |
in place of the system update, to ensure that all packages are updated. |
| 1089 |
</p> |
| 1090 |
|
| 1091 |
<pre caption="Rebuilding system"> |
| 1092 |
# <i>emerge -e system</i> |
| 1093 |
</pre> |
| 1094 |
|
| 1095 |
</body> |
| 1096 |
</section> |
| 1097 |
<section id="first-install-cleaning-up"> |
| 1098 |
<title>Cleaning up</title> |
| 1099 |
<body> |
| 1100 |
|
| 1101 |
<p> |
| 1102 |
It is also safe to remove older GCC versions at this time. Please substitute |
| 1103 |
<c>YOUR-NEW-GCC-VERSION</c> with the actual version you've upgraded to: |
| 1104 |
</p> |
| 1105 |
|
| 1106 |
<pre caption="Cleaning up"> |
| 1107 |
# <i>emerge -aC "<sys-devel/gcc-YOUR-NEW-GCC-VERSION"</i> |
| 1108 |
</pre> |
| 1109 |
|
| 1110 |
</body> |
| 1111 |
</section> |
| 1112 |
</chapter> |
| 1113 |
|
| 1114 |
<chapter id="common-pitfalls"> |
| 1115 |
<title>Common Pitfalls</title> |
| 1116 |
<section> |
| 1117 |
<body> |
| 1118 |
|
| 1119 |
<p> |
| 1120 |
It's important to disable <c>distcc</c> during upgrade. Mixing compiler versions |
| 1121 |
on your nodes <e>will</e> cause build issues. This is not required for ccache, |
| 1122 |
as the cache objects will be invalidated anyway. |
| 1123 |
</p> |
| 1124 |
|
| 1125 |
<p> |
| 1126 |
Always use same GCC version for your kernel and additional kernel modules. Once |
| 1127 |
you rebuild your world with new GCC, external modules (like |
| 1128 |
<c>app-emulation/qemu-softmmu</c>) will fail to load. Please rebuild your |
| 1129 |
kernel with the new GCC to fix that. |
| 1130 |
</p> |
| 1131 |
|
| 1132 |
<p> |
| 1133 |
If you're upgrading on a SPARC machine, make sure to rerun <c>silo -f</c> after |
| 1134 |
re-emerging world to avoid possible issues. |
| 1135 |
</p> |
| 1136 |
|
| 1137 |
</body> |
| 1138 |
</section> |
| 1139 |
<section> |
| 1140 |
<title>Frequent Error Messages</title> |
| 1141 |
<body> |
| 1142 |
|
| 1143 |
<p> |
| 1144 |
If your system complains about something like <e>libtool: link: |
| 1145 |
`/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool |
| 1146 |
archive</e>, please run |
| 1147 |
<c>/usr/share/gcc-data/$CHOST/<gcc-version>/fix_libtool_files.sh 3.3.6</c> |
| 1148 |
(substitute "3.3.6" with the version numbers from the error message, and $CHOST |
| 1149 |
and <gcc-version> with your actual CHOST and GCC version). |
| 1150 |
</p> |
| 1151 |
|
| 1152 |
<p> |
| 1153 |
If you see <e>error: /usr/bin/gcc-config: line 632: |
| 1154 |
/etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory</e>, then try |
| 1155 |
deleting <path>/etc/env.d/gcc/config-i686-pc-linux-gnu</path> and running |
| 1156 |
<c>gcc-config</c> again, followed by <c>source /etc/profile</c>. Only do this |
| 1157 |
if you do not have any cross-compilers set up, though. |
| 1158 |
</p> |
| 1159 |
|
| 1160 |
<p> |
| 1161 |
If a package fails during <c>emerge -e system</c> or <c>emerge -e world</c>, |
| 1162 |
you can resume operation with <c>emerge --resume</c>. If a package fails |
| 1163 |
repeatedly, skip it with <c>emerge --resume --skipfirst</c>. Don't run any |
| 1164 |
other instances of emerge in between or you will lose the resume information. |
| 1165 |
</p> |
| 1166 |
|
| 1167 |
<p> |
| 1168 |
If you get an error message <e>spec failure: unrecognized spec option</e> while |
| 1169 |
upgrading your compiler, try to switch back to your default compiler, unset the |
| 1170 |
<c>GCC_SPECS</c> variable and upgrade GCC again: |
| 1171 |
</p> |
| 1172 |
|
| 1173 |
<pre caption="Restoring primary specs"> |
| 1174 |
# <i>gcc-config 1</i> |
| 1175 |
# <i>source /etc/profile</i> |
| 1176 |
# <i>unset GCC_SPECS</i> |
| 1177 |
# <i>emerge -uav gcc</i> |
| 1178 |
</pre> |
| 1179 |
|
| 1180 |
</body> |
| 1181 |
</section> |
| 1182 |
</chapter> |
| 1183 |
</guide> |
Archives