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>
This commit is contained in:
Scott Rifenbark
Richard Purdie
parent
eccd321364
commit
fd381a2067
|
|
@ -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>
|
||||
|
|
|
|||
Loading…
Reference in New Issue