summaryrefslogtreecommitdiffstats
path: root/documentation/adt-manual
diff options
context:
space:
mode:
authorScott Rifenbark <scott.m.rifenbark@intel.com>2015-05-04 08:45:03 -0700
committerRichard Purdie <richard.purdie@linuxfoundation.org>2015-07-28 18:02:28 +0100
commit2a95850d641445e8b792c566f35209698ef1dd68 (patch)
tree33f7166b93f8c134b961eaa09d3fccc4697e77b0 /documentation/adt-manual
parent95108a1c346773f57ffd7f1970e2987607ad9360 (diff)
downloadpoky-2a95850d641445e8b792c566f35209698ef1dd68.tar.gz
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>
Diffstat (limited to 'documentation/adt-manual')
-rw-r--r--documentation/adt-manual/adt-prepare.xml94
1 files changed, 50 insertions, 44 deletions
diff --git a/documentation/adt-manual/adt-prepare.xml b/documentation/adt-manual/adt-prepare.xml
index 3d0cfd42fb..8776645207 100644
--- a/documentation/adt-manual/adt-prepare.xml
+++ b/documentation/adt-manual/adt-prepare.xml
@@ -622,50 +622,56 @@
622 622
623 <para> 623 <para>
624 As an alternative to locating and downloading a toolchain installer, 624 As an alternative to locating and downloading a toolchain installer,
625 you can build the toolchain installer one of two ways if you have a 625 you can build the toolchain installer if you have a
626 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>: 626 <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
627 <itemizedlist> 627 <note>
628 <listitem><para> 628 Although not the preferred method, it is also possible to use
629 Use <filename>bitbake meta-toolchain</filename>. 629 <filename>bitbake meta-toolchain</filename> to build the toolchain
630 This method requires you to still install the target 630 installer.
631 sysroot by installing and extracting it separately. 631 If you do use this method, you must separately install and extract
632 For information on how to install the sysroot, see the 632 the target sysroot.
633 "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" 633 For information on how to install the sysroot, see the
634 section. 634 "<link linkend='extracting-the-root-filesystem'>Extracting the Root Filesystem</link>"
635 </para></listitem> 635 section.
636 <listitem><para> 636 </note>
637 Use <filename>bitbake</filename> <replaceable>image</replaceable> <filename>-c populate_sdk</filename>. 637 </para>
638 This method has significant advantages over the previous method 638
639 because it results in a toolchain installer that contains the 639 <para>
640 sysroot that matches your target root filesystem. 640 To build the toolchain installer and populate the SDK image, use the
641 </para> 641 following command:
642 642 <literallayout class='monospaced'>
643 <para>Another powerful feature is that the toolchain is 643 $ bitbake <replaceable>image</replaceable> -c populate_sdk
644 completely self-contained. 644 </literallayout>
645 The binaries are linked against their own copy of 645 The command results in a toolchain installer that contains the sysroot
646 <filename>libc</filename>, which results in no dependencies 646 that matches your target root filesystem.
647 on the target system. 647 </para>
648 To achieve this, the pointer to the dynamic loader is 648
649 configured at install time since that path cannot be dynamically 649 <para>
650 altered. 650 Another powerful feature is that the toolchain is completely
651 This is the reason for a wrapper around the 651 self-contained.
652 <filename>populate_sdk</filename> archive.</para> 652 The binaries are linked against their own copy of
653 653 <filename>libc</filename>, which results in no dependencies
654 <para>Another feature is that only one set of cross-canadian 654 on the target system.
655 toolchain binaries are produced per architecture. 655 To achieve this, the pointer to the dynamic loader is
656 This feature takes advantage of the fact that the target 656 configured at install time since that path cannot be dynamically
657 hardware can be passed to <filename>gcc</filename> as a set of 657 altered.
658 compiler options. 658 This is the reason for a wrapper around the
659 Those options are set up by the environment script and 659 <filename>populate_sdk</filename> archive.
660 contained in variables such as 660 </para>
661 <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink> 661
662 and 662 <para>
663 <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>. 663 Another feature is that only one set of cross-canadian toolchain
664 This reduces the space needed for the tools. 664 binaries are produced per architecture.
665 Understand, however, that a sysroot is still needed for every 665 This feature takes advantage of the fact that the target hardware can
666 target since those binaries are target-specific. 666 be passed to <filename>gcc</filename> as a set of compiler options.
667 </para></listitem> 667 Those options are set up by the environment script and contained in
668 </itemizedlist> 668 variables such as
669 <ulink url='&YOCTO_DOCS_REF_URL;#var-CC'><filename>CC</filename></ulink>
670 and
671 <ulink url='&YOCTO_DOCS_REF_URL;#var-LD'><filename>LD</filename></ulink>.
672 This reduces the space needed for the tools.
673 Understand, however, that a sysroot is still needed for every target
674 since those binaries are target-specific.
669 </para> 675 </para>
670 676
671 <para> 677 <para>