ref-manual: Added a section reference to external toolchain question.

(From yocto-docs rev: 6b125e0e0f09e817422f899923d51ee73923b15b)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 73 insertions, 69 deletions

diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
index f96b64c1a5..688fef8503 100644
--- a/documentation/ref-manual/faq.xml
+++ b/documentation/ref-manual/faq.xml
@@ -134,10 +134,10 @@
         </question>
         <answer>
             <para>
-                Because you can use the same set of recipes to create output of 
-                various formats, the output of an OpenEmbedded build depends on 
+                Because you can use the same set of recipes to create output of
+                various formats, the output of an OpenEmbedded build depends on
                 how you start it.
-                Usually, the output is a flashable image ready for the target 
+                Usually, the output is a flashable image ready for the target
                 device.
             </para>
         </answer>
@@ -168,12 +168,12 @@
         </question>
         <answer>
             <para>
-                The OpenEmbedded build system can build packages in various 
-                formats such as IPK for OPKG, Debian package 
+                The OpenEmbedded build system can build packages in various
+                formats such as IPK for OPKG, Debian package
                 (<filename>.deb</filename>), or RPM.
-                You can then upgrade the packages using the package tools on 
-                the device, much like on a desktop distribution such as 
-                Ubuntu or Fedora. 
+                You can then upgrade the packages using the package tools on
+                the device, much like on a desktop distribution such as
+                Ubuntu or Fedora.
                 However, package management on the target is entirely optional.
             </para>
         </answer>
@@ -249,7 +249,7 @@
 
             <note>
                 <para>For information on distributions that the Yocto Project
-                uses during validation, see the 
+                uses during validation, see the
                 <ulink url='&YOCTO_WIKI_URL;/wiki/Distribution_Support'>Distribution Support</ulink>
                 Wiki page.</para>
                 <para>For notes about using the Yocto Project on a RHEL 4-based
@@ -297,8 +297,8 @@
                 </filename> = "0" in the <filename>.bb</filename> file but make sure the package is
                 manually marked as
                 machine-specific for the case that needs it.
-                The code that handles 
-                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in 
+                The code that handles
+                <filename>SRC_URI_OVERRIDES_PACKAGE_ARCH</filename> is in
                 the <filename>meta/classes/base.bbclass</filename> file.
             </para>
         </answer>
@@ -320,8 +320,8 @@
      http_proxy = http://proxy.yoyodyne.com:18023/
      ftp_proxy = http://proxy.yoyodyne.com:18023/
                 </literallayout>
-                The Yocto Project also includes a 
-                <filename>site.conf.sample</filename> file that shows how to 
+                The Yocto Project also includes a
+                <filename>site.conf.sample</filename> file that shows how to
                 configure CVS and Git proxy servers if needed.
             </para>
         </answer>
@@ -352,19 +352,19 @@
         </question>
         <answer>
             <para>
-                If the same build is failing in totally different and random 
+                If the same build is failing in totally different and random
                 ways, the most likely explanation is:
                 <itemizedlist>
-                    <listitem><para>The hardware you are running the build on 
+                    <listitem><para>The hardware you are running the build on
                         has some problem.</para></listitem>
-                    <listitem><para>You are running the build under 
-                        virtualization, in which case the virtualization 
-                        probably has bugs.</para></listitem>   
+                    <listitem><para>You are running the build under
+                        virtualization, in which case the virtualization
+                        probably has bugs.</para></listitem>
                 </itemizedlist>
-                The OpenEmbedded build system processes a massive amount of 
-                data that causes lots of network, disk and CPU activity and 
+                The OpenEmbedded build system processes a massive amount of
+                data that causes lots of network, disk and CPU activity and
                 is sensitive to even single-bit failures in any of these areas.
-                True random failures have always been traced back to hardware 
+                True random failures have always been traced back to hardware
                 or virtualization issues.
             </para>
         </answer>
@@ -378,18 +378,18 @@
         </question>
         <answer>
             <para>
-                This is a difficult question and you need to consult your lawyer 
+                This is a difficult question and you need to consult your lawyer
                 for the answer for your specific case.
-                It is worth bearing in mind that for GPL compliance, there needs 
-                to be enough information shipped to allow someone else to 
+                It is worth bearing in mind that for GPL compliance, there needs
+                to be enough information shipped to allow someone else to
                 rebuild and produce the same end result you are shipping.
-                This means sharing the source code, any patches applied to it, 
-                and also any configuration information about how that package 
+                This means sharing the source code, any patches applied to it,
+                and also any configuration information about how that package
                 was configured and built.
             </para>
 
             <para>
-                You can find more information on licensing in the 
+                You can find more information on licensing in the
                 "<ulink url='&YOCTO_DOCS_DEV_URL;#licensing'>Licensing</ulink>"
                 and "<ulink url='&YOCTO_DOCS_DEV_URL;#maintaining-open-source-license-compliance-during-your-products-lifecycle'>Maintaining Open Source License Compliance During Your Product's Lifecycle</ulink>"
                 sections, both of which are in the Yocto Project Development
@@ -410,7 +410,7 @@
                 "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
                 Developer's Guide.
-                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to 
+                Set the <filename>HAVE_TOUCHSCREEN</filename> variable equal to
                 one as follows:
                 <literallayout class='monospaced'>
      HAVE_TOUCHSCREEN=1
@@ -433,7 +433,7 @@
                 file.
                 See the "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-filelayout-misc-recipes'>Miscellaneous BSP-Specific Recipe Files</ulink>"
                 section in the Yocto Project Board Support Packages (BSP)
-                Developer's Guide for information on creating these types of 
+                Developer's Guide for information on creating these types of
                 miscellaneous recipe files.
             </para>
             <para>
@@ -454,32 +454,32 @@
         </question>
         <answer>
             <para>
-                By default, the OpenEmbedded build system creates images 
+                By default, the OpenEmbedded build system creates images
                 that are 1.3 times the size of the populated root filesystem.
-                To affect the image size, you need to set various 
+                To affect the image size, you need to set various
                 configurations:
                 <itemizedlist>
                     <listitem><para><emphasis>Image Size:</emphasis>
-                        The OpenEmbedded build system uses the 
+                        The OpenEmbedded build system uses the
                         <link linkend='var-IMAGE_ROOTFS_SIZE'><filename>IMAGE_ROOTFS_SIZE</filename></link>
-                        variable to define the size of the image in Kbytes. 
-                        The build system determines the size by taking into 
+                        variable to define the size of the image in Kbytes.
+                        The build system determines the size by taking into
                         account the initial root filesystem size before any
-                        modifications such as requested size for the image and 
-                        any requested additional free disk space to be 
+                        modifications such as requested size for the image and
+                        any requested additional free disk space to be
                         added to the image.</para></listitem>
                     <listitem><para><emphasis>Overhead:</emphasis>
-                        Use the 
+                        Use the
                         <link linkend='var-IMAGE_OVERHEAD_FACTOR'><filename>IMAGE_OVERHEAD_FACTOR</filename></link>
-                        variable to define the multiplier that the build system 
-                        applies to the initial image size, which is 1.3 by 
+                        variable to define the multiplier that the build system
+                        applies to the initial image size, which is 1.3 by
                         default.</para></listitem>
                     <listitem><para><emphasis>Additional Free Space:</emphasis>
-                        Use the 
+                        Use the
                         <link linkend='var-IMAGE_ROOTFS_EXTRA_SPACE'><filename>IMAGE_ROOTFS_EXTRA_SPACE</filename></link>
                         variable to add additional free space to the image.
                         The build system adds this space to the image after
-                        it determines its 
+                        it determines its
                         <filename>IMAGE_ROOTFS_SIZE</filename>.
                         </para></listitem>
                 </itemizedlist>
@@ -495,11 +495,11 @@
         </question>
         <answer>
             <para>
-                The Yocto Project team has tried to do this before but too 
-                many of the tools the OpenEmbedded build system depends on, 
-                such as <filename>autoconf</filename>, break when they find 
+                The Yocto Project team has tried to do this before but too
+                many of the tools the OpenEmbedded build system depends on,
+                such as <filename>autoconf</filename>, break when they find
                 spaces in pathnames.
-                Until that situation changes, the team will not support spaces 
+                Until that situation changes, the team will not support spaces
                 in pathnames.
             </para>
         </answer>
@@ -515,11 +515,11 @@
             <para>
                 The toolchain configuration is very flexible and customizable.
                 It is primarily controlled with the
-                <filename><link linkend='var-TCMODE'>TCMODE</link></filename> 
+                <filename><link linkend='var-TCMODE'>TCMODE</link></filename>
                 variable.
-                This variable controls which <filename>tcmode-*.inc</filename> 
-                file to include from the 
-                <filename>meta/conf/distro/include</filename> directory within 
+                This variable controls which <filename>tcmode-*.inc</filename>
+                file to include from the
+                <filename>meta/conf/distro/include</filename> directory within
                 the
                 <ulink url='&YOCTO_DOCS_DEV_URL;#source-directory'>Source Directory</ulink>.
             </para>
@@ -528,33 +528,37 @@
                 The default value of <filename>TCMODE</filename> is "default"
                 (i.e. <filename>tcmode-default.inc</filename>).
                 However, other patterns are accepted.
-                In particular, "external-*" refers to external toolchains of 
-                which there are some basic examples included in the 
+                In particular, "external-*" refers to external toolchains of
+                which there are some basic examples included in the
                 OpenEmbedded Core (<filename>meta</filename>).
-                You can use your own custom toolchain definition in your own 
-                layer (or as defined in the <filename>local.conf</filename> 
+                You can use your own custom toolchain definition in your own
+                layer (or as defined in the <filename>local.conf</filename>
                 file) at the location
                 <filename>conf/distro/include/tcmode-*.inc</filename>.
             </para>
 
             <para>
-                In addition to the toolchain configuration, you also need a 
+                In addition to the toolchain configuration, you also need a
                 corresponding toolchain recipe file.
-                This recipe file needs to package up any pre-built objects in 
-                the toolchain such as <filename>libgcc</filename>, 
-                <filename>libstdcc++</filename>, any locales, and 
+                This recipe file needs to package up any pre-built objects in
+                the toolchain such as <filename>libgcc</filename>,
+                <filename>libstdcc++</filename>, any locales, and
                 <filename>libc</filename>.
-                An example is the 
-                <filename>external-sourcery-toolchain.bb</filename>, which is 
-                located in <filename>meta/recipes-core/meta/</filename> within 
+                An example is the
+                <filename>external-sourcery-toolchain.bb</filename>, which is
+                located in <filename>meta/recipes-core/meta/</filename> within
                 the Source Directory.
             </para>
 
             <para>
-                For information on installing and using cross-development 
-                toolchains, see the 
+                For information on installing and using cross-development
+                toolchains, see the
                 "<ulink url='&YOCTO_DOCS_ADT_URL;#installing-the-adt'>Installing the ADT and Toolchains</ulink>"
                 section in the Yocto Project Application Developer's Guide.
+                For general information on cross-development toolchains, see
+                the
+                "<link linkend='cross-development-toolchain-generation'>Cross-Development Toolchain Generation</link>"
+                section.
             </para>
         </answer>
     </qandaentry>
@@ -625,7 +629,7 @@
                  <literallayout class='monospaced'>
      BB_FETCH_PREMIRRORONLY = "1"
                  </literallayout>
-                 This statement limits the build system to pulling source 
+                 This statement limits the build system to pulling source
                  from the <filename>PREMIRRORS</filename> only.
                  Again, this technique is useful for reproducing builds.
              </para>
@@ -634,7 +638,7 @@
                  <literallayout class='monospaced'>
      BB_GENERATE_MIRROR_TARBALLS = "1"
                  </literallayout>
-                 This statement tells the build system to generate mirror 
+                 This statement tells the build system to generate mirror
                  tarballs.
                  This technique is useful if you want to create a mirror server.
                  If not, however, the technique can simply waste time during
@@ -677,8 +681,8 @@
         <answer>
             <para>
                 Yes - you can easily do this.
-                When you use BitBake to build an image, all the build output 
-                goes into the directory created when you source the 
+                When you use BitBake to build an image, all the build output
+                goes into the directory created when you source the
                 <link linkend='structure-core-script'><filename>&OE_INIT_FILE;</filename></link>
                 setup script.
                 By default, this <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
@@ -687,10 +691,10 @@
             </para>
 
             <para>
-                Within the Build Directory, is the <filename>tmp</filename> 
+                Within the Build Directory, is the <filename>tmp</filename>
                 directory.
-                To remove all the build output yet preserve any source code or 
-                downloaded files from previous builds, simply remove the 
+                To remove all the build output yet preserve any source code or
+                downloaded files from previous builds, simply remove the
                 <filename>tmp</filename> directory.
             </para>
         </answer>