diff options
author | Scott Rifenbark <scott.m.rifenbark@intel.com> | 2015-05-04 08:45:03 -0700 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2015-07-28 18:02:28 +0100 |
commit | 2a95850d641445e8b792c566f35209698ef1dd68 (patch) | |
tree | 33f7166b93f8c134b961eaa09d3fccc4697e77b0 /documentation/adt-manual | |
parent | 95108a1c346773f57ffd7f1970e2987607ad9360 (diff) | |
download | poky-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.xml | 94 |
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> |