adt-manual: Emphasis on populate_sdk as bitbake method for building toolchain
I updated the "Optionally Building a Toolchain Installer" section to emphasize using 'bitbake <image> -c populate_sdk' as the method for building outa toolchain. Before the change, equal emphasis was put on for this preferred method and the 'bitbake meta-toolchain' method. (From yocto-docs rev: 447ad6167570bf1bd227771153de421d1154443d) Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
parent
95108a1c34
commit
2a95850d64
|
@ -622,50 +622,56 @@
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
As an alternative to locating and downloading a toolchain installer,
|
As an alternative to locating and downloading a toolchain installer,
|
||||||
you can build the toolchain installer one of two ways if you have a
|
you can build the toolchain installer if you have a
|
||||||
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>:
|
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
|
||||||
<itemizedlist>
|
<note>
|
||||||
<listitem><para>
|
Although not the preferred method, it is also possible to use
|
||||||
Use <filename>bitbake meta-toolchain</filename>.
|
<filename>bitbake meta-toolchain</filename> to build the toolchain
|
||||||
This method requires you to still install the target
|
installer.
|
||||||
sysroot by installing and extracting it separately.
|
If you do use this method, you must separately install and extract
|
||||||
For information on how to install the sysroot, see the
|
the target sysroot.
|
||||||
"<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
|
For information on how to install the sysroot, see the
|
||||||
section.
|
"<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
|
||||||
</para></listitem>
|
section.
|
||||||
<listitem><para>
|
</note>
|
||||||
Use <filename>bitbake</filename> <replaceable>image</replaceable> <filename>-c populate_sdk</filename>.
|
</para>
|
||||||
This method has significant advantages over the previous method
|
|
||||||
because it results in a toolchain installer that contains the
|
|
||||||
sysroot that matches your target root filesystem.
|
|
||||||
</para>
|
|
||||||
|
|
||||||
<para>Another powerful feature is that the toolchain is
|
<para>
|
||||||
completely self-contained.
|
To build the toolchain installer and populate the SDK image, use the
|
||||||
The binaries are linked against their own copy of
|
following command:
|
||||||
<filename>libc</filename>, which results in no dependencies
|
<literallayout class='monospaced'>
|
||||||
on the target system.
|
$ bitbake <replaceable>image</replaceable> -c populate_sdk
|
||||||
To achieve this, the pointer to the dynamic loader is
|
</literallayout>
|
||||||
configured at install time since that path cannot be dynamically
|
The command results in a toolchain installer that contains the sysroot
|
||||||
altered.
|
that matches your target root filesystem.
|
||||||
This is the reason for a wrapper around the
|
</para>
|
||||||
<filename>populate_sdk</filename> archive.</para>
|
|
||||||
|
|
||||||
<para>Another feature is that only one set of cross-canadian
|
<para>
|
||||||
toolchain binaries are produced per architecture.
|
Another powerful feature is that the toolchain is completely
|
||||||
This feature takes advantage of the fact that the target
|
self-contained.
|
||||||
hardware can be passed to <filename>gcc</filename> as a set of
|
The binaries are linked against their own copy of
|
||||||
compiler options.
|
<filename>libc</filename>, which results in no dependencies
|
||||||
Those options are set up by the environment script and
|
on the target system.
|
||||||
contained in variables such as
|
To achieve this, the pointer to the dynamic loader is
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
|
configured at install time since that path cannot be dynamically
|
||||||
and
|
altered.
|
||||||
<ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>.
|
This is the reason for a wrapper around the
|
||||||
This reduces the space needed for the tools.
|
<filename>populate_sdk</filename> archive.
|
||||||
Understand, however, that a sysroot is still needed for every
|
</para>
|
||||||
target since those binaries are target-specific.
|
|
||||||
</para></listitem>
|
<para>
|
||||||
</itemizedlist>
|
Another feature is that only one set of cross-canadian toolchain
|
||||||
|
binaries are produced per architecture.
|
||||||
|
This feature takes advantage of the fact that the target hardware can
|
||||||
|
be passed to <filename>gcc</filename> as a set of compiler options.
|
||||||
|
Those options are set up by the environment script and contained in
|
||||||
|
variables such as
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
|
||||||
|
and
|
||||||
|
<ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>.
|
||||||
|
This reduces the space needed for the tools.
|
||||||
|
Understand, however, that a sysroot is still needed for every target
|
||||||
|
since those binaries are target-specific.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
|
|
Loading…
Reference in New Issue