diff options
| -rw-r--r-- | chapter05/gcc-pass1.xml | 4 | ||||
| -rw-r--r-- | chapter05/gcc-pass2.xml | 4 | ||||
| -rw-r--r-- | chapter06/gcc.xml | 15 | ||||
| -rw-r--r-- | chapter06/pkgmgt.xml | 12 |
4 files changed, 22 insertions, 13 deletions
diff --git a/chapter05/gcc-pass1.xml b/chapter05/gcc-pass1.xml index b0fd383f8..49612eba7 100644 --- a/chapter05/gcc-pass1.xml +++ b/chapter05/gcc-pass1.xml @@ -105,6 +105,10 @@ done</userinput></screen> <screen><userinput remap="pre">sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure</userinput></screen> + <para>Also fix a problem identified upstream:</para> + +<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&\& \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen> + <para>The GCC documentation recommends building GCC outside of the source directory in a dedicated build directory:</para> diff --git a/chapter05/gcc-pass2.xml b/chapter05/gcc-pass2.xml index 1dce58834..1bd4c4a20 100644 --- a/chapter05/gcc-pass2.xml +++ b/chapter05/gcc-pass2.xml @@ -95,6 +95,10 @@ mv -v gmp-&gmp-extracted-version; gmp tar -xf ../mpc-&mpc-version;.tar.gz mv -v mpc-&mpc-version; mpc</userinput></screen> + <para>As in the first build of GCC, fix a problem identified upstream:</para> + +<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&\& \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen> + <para>Create a separate build directory again:</para> <screen><userinput remap="pre">mkdir -v ../gcc-build diff --git a/chapter06/gcc.xml b/chapter06/gcc.xml index e7efba79a..8dc997b01 100644 --- a/chapter06/gcc.xml +++ b/chapter06/gcc.xml @@ -40,6 +40,11 @@ <sect2 role="installation"> <title>Installation of GCC</title> + + <para>As in Chapter 5, fix a problem identified upstream:</para> + +<screen><userinput remap="pre">sed -i 's/if \((code.*))\)/if (\1 \&\& \!DEBUG_INSN_P (insn))/' gcc/sched-deps.c</userinput></screen> + <!-- <para>First fix a problem identified upstream that causes some programs to fail:</para> @@ -130,10 +135,10 @@ cd ../gcc-build</userinput></screen> url="&test-results;"/> and <ulink url="http://gcc.gnu.org/ml/gcc-testresults/"/>.</para> <para>A few unexpected failures cannot always be avoided. The GCC developers - are usually aware of these issues, but have not resolved them yet. In + are usually aware of these issues, but have not resolved them yet. <!-- In particular, the <filename class="libraryfile">libmudflap</filename> tests are known to be particularly problematic as a result of a bug in GCC - (<ulink url="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003"/>). + (<ulink url="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20003"/>). --> Unless the test results are vastly different from those at the above URL, it is safe to continue.</para> @@ -321,7 +326,7 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib</userinput></screen> <seg>libasan.{a,so}, libatomic.{a,so}, libgcc.a, libgcc_eh.a, libgcc_s.so, libgcov.a, libgomp.{a,so}, libiberty.a, libitm.{a,so}, - liblto_plugin.so, libmudflap.{a,so}, libmudflapth.{a,so}, + liblto_plugin.so, libquadmath.{a,so}, libssp.{a,so}, libssp_nonshared.a, libstdc++.{a,so}, libsupc++.a and libtsan.{a,so}</seg> @@ -501,7 +506,7 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib</userinput></screen> </indexterm> </listitem> </varlistentry> - +<!-- <varlistentry id="libmudflap"> <term><filename class="libraryfile">libmudflap</filename></term> <listitem> @@ -512,7 +517,7 @@ mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib</userinput></screen> </indexterm> </listitem> </varlistentry> - +--> <varlistentry id="libquadmath"> <term><filename class="libraryfile">libquadmath</filename></term> <listitem> diff --git a/chapter06/pkgmgt.xml b/chapter06/pkgmgt.xml index 67ffd1cd7..b4734aba0 100644 --- a/chapter06/pkgmgt.xml +++ b/chapter06/pkgmgt.xml @@ -51,14 +51,10 @@ <itemizedlist> <listitem> - <para>If one of the toolchain packages (Glibc, GCC or Binutils) needs - to be upgraded to a newer minor version, it is safer to rebuild LFS. - Though you <emphasis>may</emphasis> be able to get by rebuilding all - the packages in their dependency order, we do not recommend it. For - example, if glibc-2.2.x needs to be updated to glibc-2.3.x, it is safer - to rebuild. For micro version updates, a simple reinstallation usually - works, but is not guaranteed. For example, upgrading from glibc-2.3.4 - to glibc-2.3.5 will not usually cause any problems.</para> + <para>If Glibc needs to be upgraded to a newer version, (e.g. from + glibc-2.19 to glibc-2.20, it is safer to rebuild LFS. Though you + <emphasis>may</emphasis> be able to rebuild all the packages in their + dependency order, we do not recommend it. </para> </listitem> <listitem> |