From fd381a206763bfac46dffc049f529492a8abe9d5 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Thu, 25 Jul 2013 10:51:33 +0300 Subject: [PATCH] ref-manual: Added a section reference to external toolchain question. (From yocto-docs rev: 6b125e0e0f09e817422f899923d51ee73923b15b) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/faq.xml | 142 ++++++++++++++++--------------- 1 file 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 @@ - 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. @@ -168,12 +168,12 @@ - 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 (.deb), 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. @@ -249,7 +249,7 @@ For information on distributions that the Yocto Project - uses during validation, see the + uses during validation, see the Distribution Support Wiki page. For notes about using the Yocto Project on a RHEL 4-based @@ -297,8 +297,8 @@ = "0" in the .bb file but make sure the package is manually marked as machine-specific for the case that needs it. - The code that handles - SRC_URI_OVERRIDES_PACKAGE_ARCH is in + The code that handles + SRC_URI_OVERRIDES_PACKAGE_ARCH is in the meta/classes/base.bbclass file. @@ -320,8 +320,8 @@ http_proxy = http://proxy.yoyodyne.com:18023/ ftp_proxy = http://proxy.yoyodyne.com:18023/ - The Yocto Project also includes a - site.conf.sample file that shows how to + The Yocto Project also includes a + site.conf.sample file that shows how to configure CVS and Git proxy servers if needed. @@ -352,19 +352,19 @@ - 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: - The hardware you are running the build on + The hardware you are running the build on has some problem. - You are running the build under - virtualization, in which case the virtualization - probably has bugs. + You are running the build under + virtualization, in which case the virtualization + probably has bugs. - 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. @@ -378,18 +378,18 @@ - 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. - You can find more information on licensing in the + You can find more information on licensing in the "Licensing" and "Maintaining Open Source License Compliance During Your Product's Lifecycle" sections, both of which are in the Yocto Project Development @@ -410,7 +410,7 @@ "Miscellaneous BSP-Specific Recipe Files" section in the Yocto Project Board Support Packages (BSP) Developer's Guide. - Set the HAVE_TOUCHSCREEN variable equal to + Set the HAVE_TOUCHSCREEN variable equal to one as follows: HAVE_TOUCHSCREEN=1 @@ -433,7 +433,7 @@ file. See the "Miscellaneous BSP-Specific Recipe Files" 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. @@ -454,32 +454,32 @@ - 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: Image Size: - The OpenEmbedded build system uses the + The OpenEmbedded build system uses the IMAGE_ROOTFS_SIZE - 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. Overhead: - Use the + Use the IMAGE_OVERHEAD_FACTOR - 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. Additional Free Space: - Use the + Use the IMAGE_ROOTFS_EXTRA_SPACE 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 IMAGE_ROOTFS_SIZE. @@ -495,11 +495,11 @@ - The Yocto Project team has tried to do this before but too - many of the tools the OpenEmbedded build system depends on, - such as autoconf, 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 autoconf, 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. @@ -515,11 +515,11 @@ The toolchain configuration is very flexible and customizable. It is primarily controlled with the - TCMODE + TCMODE variable. - This variable controls which tcmode-*.inc - file to include from the - meta/conf/distro/include directory within + This variable controls which tcmode-*.inc + file to include from the + meta/conf/distro/include directory within the Source Directory. @@ -528,33 +528,37 @@ The default value of TCMODE is "default" (i.e. tcmode-default.inc). 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 (meta). - You can use your own custom toolchain definition in your own - layer (or as defined in the local.conf + You can use your own custom toolchain definition in your own + layer (or as defined in the local.conf file) at the location conf/distro/include/tcmode-*.inc. - 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 libgcc, - libstdcc++, any locales, and + This recipe file needs to package up any pre-built objects in + the toolchain such as libgcc, + libstdcc++, any locales, and libc. - An example is the - external-sourcery-toolchain.bb, which is - located in meta/recipes-core/meta/ within + An example is the + external-sourcery-toolchain.bb, which is + located in meta/recipes-core/meta/ within the Source Directory. - For information on installing and using cross-development - toolchains, see the + For information on installing and using cross-development + toolchains, see the "Installing the ADT and Toolchains" section in the Yocto Project Application Developer's Guide. + For general information on cross-development toolchains, see + the + "Cross-Development Toolchain Generation" + section. @@ -625,7 +629,7 @@ BB_FETCH_PREMIRRORONLY = "1" - This statement limits the build system to pulling source + This statement limits the build system to pulling source from the PREMIRRORS only. Again, this technique is useful for reproducing builds. @@ -634,7 +638,7 @@ BB_GENERATE_MIRROR_TARBALLS = "1" - 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 @@ 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 &OE_INIT_FILE; setup script. By default, this Build Directory @@ -687,10 +691,10 @@ - Within the Build Directory, is the tmp + Within the Build Directory, is the tmp 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 tmp directory.