From: "Jan Kundrat" <jkt@lark.gentoo.org>
To: gentoo-doc-cvs@lists.gentoo.org
Subject: [gentoo-doc-cvs] cvs commit: gcc-upgrading.xml
Date: Thu, 9 Feb 2006 16:15:21 +0000 [thread overview]
Message-ID: <200602091615.k19GFMUj021112@robin.gentoo.org> (raw)
jkt 06/02/09 16:15:21
Modified: xml/htdocs/doc/en gcc-upgrading.xml
Log:
Moving the "common-pitfalls" section to the end of the document
Revision Changes Path
1.8 +65 -65 xml/htdocs/doc/en/gcc-upgrading.xml
file : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/gcc-upgrading.xml?rev=1.8&content-type=text/x-cvsweb-markup&cvsroot=gentoo
plain: http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/gcc-upgrading.xml?rev=1.8&content-type=text/plain&cvsroot=gentoo
diff : http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/doc/en/gcc-upgrading.xml.diff?r1=1.7&r2=1.8&cvsroot=gentoo
Index: gcc-upgrading.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- gcc-upgrading.xml 9 Feb 2006 16:06:51 -0000 1.7
+++ gcc-upgrading.xml 9 Feb 2006 16:15:21 -0000 1.8
@@ -1,5 +1,5 @@
<?xml version='1.0' encoding="UTF-8"?>
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v 1.7 2006/02/09 16:06:51 jkt Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/doc/en/gcc-upgrading.xml,v 1.8 2006/02/09 16:15:21 jkt Exp $ -->
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
@@ -25,7 +25,7 @@
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
<license/>
-<version>6</version>
+<version>7</version>
<date>2006-02-09</date>
<chapter id="intro">
@@ -295,69 +295,6 @@
</section>
</chapter>
-<chapter id="common-pitfalls">
-<title>Common Pitfalls</title>
-<section>
-<body>
-
-<p>
-It's important to disable <c>distcc</c> during upgrade. Mixing compiler versions
-on your nodes <e>will</e> cause build issues. This is not required for ccache,
-as the cache objects will be invalidated anyway.
-</p>
-
-<p>
-Always use same GCC version for your kernel and additional kernel modules. Once
-you rebuild your world with new GCC, external modules (like
-<c>app-emulation/qemu-softmmu</c>) will fail to load. Please rebuild your kernel
-with new GCC to fix that.
-</p>
-
-</body>
-</section>
-<section>
-<title>Frequent Error Messages</title>
-<body>
-
-<p>
-If your system complains about something like <e>libtool: link:
-`/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool
-archive</e>, please run <c>/sbin/fix_libtool_files.sh 3.3.6</c> (substitute
-"3.3.6" with the version numbers from the error message).
-</p>
-
-<p>
-If you see the <e>error: /usr/bin/gcc-config: line 632:
-/etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory</e>, then try
-deleting <path>/etc/env.d/gcc/config-i686-pc-linux-gnu</path> and running
-<c>gcc-config</c> again, followed by <c>source /etc/profile</c>. Only do this if
-you do not have any cross-compilers set up, though.
-</p>
-
-<p>
-If a package fails during <c>emerge -e system</c> or <c>emerge -e world</c>,
-you can resume operation with <c>emerge --resume</c>. If a package fails
-repeatedly, skip it with <c>emerge --resume --skipfirst</c>. Don't run any
-other instances of emerge in between or you will lose the resume information.
-</p>
-
-<p>
-If you get an error message <e>spec failure: unrecognized spec option</e> while
-upgrading your compiler, try to switch back to your default compiler, unset the
-<c>GCC_SPECS</c> variable and upgrade GCC again:
-</p>
-
-<pre caption="Restoring primary specs">
-# <i>gcc-config 1</i>
-# <i>source /etc/profile</i>
-# <i>unset GCC_SPECS</i>
-# <i>emerge -uav gcc</i>
-</pre>
-
-</body>
-</section>
-</chapter>
-
<chapter id="first-install">
<title>Upgrading to GCC on a First Install</title>
<section>
@@ -503,4 +440,67 @@
</body>
</section>
</chapter>
+
+<chapter id="common-pitfalls">
+<title>Common Pitfalls</title>
+<section>
+<body>
+
+<p>
+It's important to disable <c>distcc</c> during upgrade. Mixing compiler versions
+on your nodes <e>will</e> cause build issues. This is not required for ccache,
+as the cache objects will be invalidated anyway.
+</p>
+
+<p>
+Always use same GCC version for your kernel and additional kernel modules. Once
+you rebuild your world with new GCC, external modules (like
+<c>app-emulation/qemu-softmmu</c>) will fail to load. Please rebuild your kernel
+with new GCC to fix that.
+</p>
+
+</body>
+</section>
+<section>
+<title>Frequent Error Messages</title>
+<body>
+
+<p>
+If your system complains about something like <e>libtool: link:
+`/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.la' is not a valid libtool
+archive</e>, please run <c>/sbin/fix_libtool_files.sh 3.3.6</c> (substitute
+"3.3.6" with the version numbers from the error message).
+</p>
+
+<p>
+If you see the <e>error: /usr/bin/gcc-config: line 632:
+/etc/env.d/gcc/i686-pc-linux-gnu-3.3.5: No such file or directory</e>, then try
+deleting <path>/etc/env.d/gcc/config-i686-pc-linux-gnu</path> and running
+<c>gcc-config</c> again, followed by <c>source /etc/profile</c>. Only do this if
+you do not have any cross-compilers set up, though.
+</p>
+
+<p>
+If a package fails during <c>emerge -e system</c> or <c>emerge -e world</c>,
+you can resume operation with <c>emerge --resume</c>. If a package fails
+repeatedly, skip it with <c>emerge --resume --skipfirst</c>. Don't run any
+other instances of emerge in between or you will lose the resume information.
+</p>
+
+<p>
+If you get an error message <e>spec failure: unrecognized spec option</e> while
+upgrading your compiler, try to switch back to your default compiler, unset the
+<c>GCC_SPECS</c> variable and upgrade GCC again:
+</p>
+
+<pre caption="Restoring primary specs">
+# <i>gcc-config 1</i>
+# <i>source /etc/profile</i>
+# <i>unset GCC_SPECS</i>
+# <i>emerge -uav gcc</i>
+</pre>
+
+</body>
+</section>
+</chapter>
</guide>
--
gentoo-doc-cvs@gentoo.org mailing list
next reply other threads:[~2006-02-09 16:15 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-09 16:15 Jan Kundrat [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-08-03 3:35 [gentoo-doc-cvs] cvs commit: gcc-upgrading.xml Joshua Saddler
2008-05-19 21:02 Sven Vermeulen
2007-04-02 23:13 Jan Kundrat
2006-10-06 17:41 Josh Saddler
2006-09-13 23:39 Jan Kundrat
2006-09-13 23:20 Jan Kundrat
2006-09-13 14:52 Jan Kundrat
2006-09-13 14:42 Jan Kundrat
2006-09-07 11:06 Lukasz Damentko
2006-09-06 2:14 vapier
2006-09-04 20:48 Josh Saddler
2006-09-02 5:18 Lukasz Damentko
2006-09-02 4:16 vapier
2006-08-31 0:08 Josh Saddler
2006-05-26 20:45 Josh Saddler
2006-03-01 20:17 Jan Kundrat
2006-03-01 1:54 Marcelo Goes
2006-02-25 9:37 Jan Kundrat
2006-02-09 17:40 Jan Kundrat
2006-02-09 16:06 Jan Kundrat
2006-02-02 15:59 Xavier Neys
2006-01-30 15:32 Jan Kundrat
2005-12-14 20:03 Jan Kundrat
2005-12-12 15:41 Jan Kundrat
2005-12-08 19:25 Jan Kundrat
2005-12-08 19:21 Jan Kundrat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200602091615.k19GFMUj021112@robin.gentoo.org \
--to=jkt@lark.gentoo.org \
--cc=docs-team@lists.gentoo.org \
--cc=gentoo-doc-cvs@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox