mirrors/poky
1
0
Fork 0
mirror of https://git.yoctoproject.org/poky synced 2026-09-25 07:36:23 +02:00
Code Issues Packages Projects Releases Wiki Activity

sdk-manual: Edits to add extensible SDK configuration sections.

Browse Source 
(From yocto-docs rev: 378bbceb8ea06c225c4758807e25a35521faa3a9)

Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark
2016-03-21 14:25:47 -07:00
committed by Richard Purdie
parent b31bf7c68b
commit 7233e359dd
4 changed files with 504 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files

379
documentation/sdk-manual/sdk-appendix-customizing.xml
View File

@@ -6,17 +6,380 @@
<title>Customizing the SDK</title> <title>Customizing the SDK</title>
<para role='writernotes'> <para>
This chapter is going to cover the details on extending the SDK through This appendix presents customizations you can apply to both the standard
user customizations. and extensible SDK.
I am not sure if this is possible for both the standard and extensible Each subsection identifies the type of SDK to which the section applies.
SDK or what.
</para> </para>
<para role='writernotes'> <section id='sdk-configuring-the-extensible-sdk'>
I do not have a feel for what sub-topics need to be covered here. <title>Configuring the Extensible SDK</title>
I need to get this information from Paul.
<para>
The extensible SDK primarily consists of a pre-configured copy of
the build system from which it was produced.
Thus, the SDK's configuration is derived using that build system.
However, filters exist that are applied such as the following that
are applied to <filename>local.conf</filename> and
<filename>auto.conf</filename> when present:
<itemizedlist>
<listitem><para>
Variables whose values start with "/" are excluded since the
assumption is that those values are paths that are likely to
be specific to the build host.
</para></listitem>
<listitem><para>
Variables listed in
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_BLACKLIST'><filename>SDK_LOCAL_CONF_BLACKLIST</filename></ulink>
are excluded.
The default value blacklists
<ulink url='&YOCTO_DOCS_REF_URL;#var-CONF_VERSION'><filename>CONF_VERSION</filename></ulink>,
<ulink url='&YOCTO_DOCS_REF_URL;#var-BB_NUMBER_THREADS'><filename>BB_NUMBER_THREADS</filename></ulink>,
<ulink url='&YOCTO_DOCS_REF_URL;#var-PARALLEL_MAKE'><filename>PARALLEL_MAKE</filename></ulink>,
<ulink url='&YOCTO_DOCS_REF_URL;#var-PRSERV_HOST'><filename>PRSERV_HOST</filename></ulink>,
and
<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink>.
</para></listitem>
<listitem><para>
Variables listed in
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_LOCAL_CONF_WHITELIST'><filename>SDK_LOCAL_CONF_WHITELIST</filename></ulink>
are included.
Including these variables overrides either of the above two
conditions.
The default value is blank.
</para></listitem>
<listitem><para>
Classes inherited globally with
<ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink>
that are listed in
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
are disabled.
Using <filename>SDK_INHERIT_BLACKLIST</filename> to disable
these classes is is the typical method to disable classes that
are problematic or unnecessary in the SDK context.
The default value blacklists the
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-buildhistory'><filename>buildhistory</filename></ulink>
and
<ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-icecc'><filename>icecc</filename></ulink>
classes.
</para></listitem>
</itemizedlist>
Additionally, the contents of <filename>conf/sdk-extra.conf</filename>,
when present, are appended to the end of
<filename>conf/local.conf</filename> within the produced SDK, without
any filtering.
Not filtering these contents is particularly useful if you want to
set a variable value just for the SDK and not the build system used to
create the SDK.
</para> </para>
</section>
<section id='adjusting-the-extensible-sdk-to-suit-your-build-system-setup'>
<title>Adjusting the Extensible SDK to Suit Your Build System Setup</title>
<para>
In most cases, the extensible SDK defaults should work.
However, some cases exist for which you might consider making
adjustments:
<itemizedlist>
<listitem><para>
If your SDK configuration inherits additional classes
using the
<ulink url='&YOCTO_DOCS_REF_URL;#var-INHERIT'><filename>INHERIT</filename></ulink>
variable and you do not need or want those classes enabled in
the SDK, you can blacklist them by adding them to the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INHERIT_BLACKLIST'><filename>SDK_INHERIT_BLACKLIST</filename></ulink>
variable.
The default value of <filename>SDK_INHERIT_BLACKLIST</filename>
is set using the "?=" operator.
Consequently, you will need to either set the complete value
using "=" or append the value using "_append".
</para></listitem>
<listitem><para>
If you have classes or recipes that add additional tasks to
the standard build flow (i.e. that execute as part of building
the recipe as opposed to needing to be called explicitly), then
you need to do one of the following:
<itemizedlist>
<listitem><para>
Ensure the tasks are shared state tasks (i.e. their
output is saved to and can be restored from the shared
state cache), or that the tasks are able to be
produced quickly from a task that is a shared state
task and add the task name to the value of
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_RECRDEP_TASKS'><filename>SDK_RECRDEP_TASKS</filename></ulink>.
</para></listitem>
<listitem><para>
Disable the tasks if they are added by a class and
you do not need the functionality the class provides
in the extensible SDK.
To disable the tasks, add the class to
<filename>SDK_INHERIT_BLACKLIST</filename> as previously
described.
</para></listitem>
</itemizedlist>
</para></listitem>
<listitem><para>
Generally, you want to have a shared state mirror set up so
users of the SDK can add additional items to the SDK after
installation without needing to build the items from source.
See the
"<link linkend='sdk-providing-additional-installable-extensible-sdk-content'>Providing Additional Installable Extensible SDK Content</link>"
section for information.
</para></listitem>
<listitem><para>
If you want users of the SDK to be able to easily update the
SDK, you need to set the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
variable.
For more information, see the
"<link linkend='sdk-providing-updates-after-installing-the-extensible-sdk'>Providing Updates After Installing the Extensible SDK</link>"
section.
</para></listitem>
<listitem><para>
If you have adjusted the list of files and directories that
appear in
<ulink url='&YOCTO_DOCS_REF_URL;#var-COREBASE'><filename>COREBASE</filename></ulink>
(other than layers that are enabled through
<filename>bblayers.conf</filename>), then must list these
files in
<ulink url='&YOCTO_DOCS_REF_URL;#var-COREBASE_FILES'><filename>COREBASE_FILES</filename></ulink>
so that the files are copied into the SDK.
</para></listitem>
<listitem><para>
If your build system setup uses a different environment setup
script other than
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
or
<ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>,
then you must set
<ulink url='&YOCTO_DOCS_REF_URL;#var-OE_INIT_ENV_SCRIPT'><filename>OE_INIT_ENV_SCRIPT</filename></ulink>
to point to the environment setup script you use.
<note>
You must also reflect this change in the value used for the
<filename>COREBASE_FILES</filename> variable as previously
described.
</note>
</para></listitem>
</itemizedlist>
</para>
</section>
<section id='sdk-changing-the-appearance-of-the-extensible-sdk'>
<title>Changing the Appearance of the Extensible SDK</title>
<para>
You can change the title shown by the SDK installer by setting the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_TITLE'><filename>SDK_TITLE</filename></ulink>
variable.
By default, this title is derived from
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO_NAME'><filename>DISTRO_NAME</filename></ulink>
when it is set.
If the <filename>DISTRO_NAME</filename> variable is not set, the title
is derived from the
<ulink url='&YOCTO_DOCS_REF_URL;#var-DISTRO'><filename>DISTRO</filename></ulink>
variable.
</para>
</section>
<section id='sdk-providing-updates-after-installing-the-extensible-sdk'>
<title>Providing Updates After Installing the Extensible SDK</title>
<para>
When you make changes to your configuration or to the metadata and
if you want those changes to be reflected in installed SDKs, you need
to perform additional steps to make it possible for those that use
the SDK to update their installations with the
<filename>devtool sdk-update</filename> command:
<orderedlist>
<listitem><para>
Arrange to be created a directory that can be shared over
HTTP or HTTPS.
</para></listitem>
<listitem><para>
Set the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_UPDATE_URL'><filename>SDK_UPDATE_URL</filename></ulink>
variable to point to the corresponding HTTP or HTTPS URL.
Setting this variable causes any SDK built to default to that
URL and thus, the user does not have to pass the URL to the
<filename>devtool sdk-update</filename> command.
</para></listitem>
<listitem><para>
Build the extensible SDK normally (i.e., use the
<filename>bitbake -c populate_sdk_ext</filename> <replaceable>imagename</replaceable>
command).
</para></listitem>
<listitem><para>
Publish the SDK using the following command:
<literallayout class='monospaced'>
$ oe-publish-sdk <replaceable>some_path</replaceable>/sdk-installer.sh <replaceable>path_to_shared/http_directory</replaceable>
</literallayout>
You must repeat this step each time you rebuild the SDK
with changes that you want to make available through the
update mechanism.
</para></listitem>
</orderedlist>
</para>
<para>
Completing the above steps allows users of the existing SDKs to
simply run <filename>devtool sdk-update</filename> to retrieve the
latest updates.
See the
"<link linkend='sdk-updating-the-extensible-sdk'>Updating the Extensible SDK</link>"
section for further information.
</para>
</section>
<section id='sdk-providing-additional-installable-extensible-sdk-content'>
<title>Providing Additional Installable Extensible SDK Content</title>
<para>
If you want the users of the extensible SDK you are building to be
able to add items to the SDK without needing to build the
items from source, you need to do a number of things:
<orderedlist>
<listitem><para>
Ensure the additional items you want the user to be able to
install are actually built.
You can ensure these items are built a number of different
ways: 1) Build them explicitly, perhaps using one or more
"meta" recipes that depend on lists of other recipes to keep
things tidy, or 2) Build the "world" target and set
<filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
for the recipes you do not want built.
See the
<ulink url='&YOCTO_DOCS_REF_URL;#var-EXCLUDE_FROM_WORLD'><filename>EXCLUDE_FROM_WORLD</filename></ulink>
variable for additional information.
</para></listitem>
<listitem><para>
Expose the <filename>sstate-cache</filename> directory
produced by the build.
Typically, you expose this directory over HTTP or HTTPS.
</para></listitem>
<listitem><para>
Set the appropriate configuration so that the produced SDK
knows how to find the configuration.
The variable you need to set is
<ulink url='&YOCTO_DOCS_REF_URL;#var-SSTATE_MIRRORS'><filename>SSTATE_MIRRORS</filename></ulink>:
<literallayout class='monospaced'>
SSTATE_MIRRORS = "file://.* http://<replaceable>example</replaceable>.com/<replaceable>some_path</replaceable>/sstate-cache/PATH"
</literallayout>
You can set the <filename>SSTATE_MIRRORS</filename> variable
in two different places:
<itemizedlist>
<listitem><para>
If the mirror value you are setting is appropriate to
be set for both the build system that is actually
building the SDK and the SDK itself (i.e. the mirror
is accessible in both places or it will fail quickly
on the build system side, and its contents will not
interfere with the build), then you can set the
variable in your <filename>local.conf</filename>
or custom distro configuration file.
You can "whitelist" the variable through the SDK by
adding the following:
<literallayout class='monospaced'>
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
</literallayout>
</para></listitem>
<listitem><para>
Alternatively, if you just want to set the
<filename>SSTATE_MIRRORS</filename> variable's value
for the SDK alone, create a
<filename>conf/sdk-extra.conf</filename> either in
your
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>
or within any layer and put your
<filename>SSTATE_MIRRORS</filename> setting within
that file.
<note>
This second option is the safest option should
you have any doubts as to which method to use when
setting <filename>SSTATE_MIRRORS</filename>.
</note>
</para></listitem>
</itemizedlist>
</para></listitem>
</orderedlist>
</para>
</section>
<section id='sdk-minimizing-the-size-of-the-extensible-sdk-installer-download'>
<title>Minimizing the Size of the Extensible SDK Installer Download</title>
<para>
By default, the extensible SDK bundles the shared state artifacts for
everything needed to reconstruct the image for which the SDK was built.
This bundling can lead to an SDK installer file that is a Gigabyte or
more in size.
If the size of this file causes a problem, you can build an SDK that
has just enough in it to install and provide access to the
<filename>devtool command</filename> by setting the following in your
configuration:
<literallayout class='monospaced'>
SDK_EXT_TYPE = "minimal"
</literallayout>
Setting
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_EXT_TYPE'><filename>SDK_EXT_TYPE</filename></ulink>
to "minimal" produces an SDK installer that is around 35 Mbytes in
size, which downloads and installs quickly.
You need to realize, though, that the installer does not install any
libraries or tools out of the box.
These must be installed either "on the fly" or through actions you
perform using <filename>devtool</filename> or explicitly with the
<filename>devtool sdk-install</filename> command.
</para>
<para>
In most cases, when building a minimal SDK you will need to also enable
bringing in the information on a wider range of packages produced by
the system.
This is particularly true so that <filename>devtool add</filename>
is able to effectively map dependencies it discovers in a source tree
to the appropriate recipes.
Also so that the <filename>devtool search</filename> command
is able to return useful results.
</para>
<para>
To facilitate this wider range of information, you would additionally
set the following:
<literallayout class='monospaced'>
SDK_INCLUDE_PKGDATA = "1"
</literallayout>
See the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDK_INCLUDE_PKGDATA'><filename>SDK_INCLUDE_PKGDATA</filename></ulink>
variable for additional information.
</para>
<para>
Setting the <filename>SDK_INCLUDE_PKGDATA</filename> variable as
shown causes the "world" target to be built so that information
for all of the recipes included within it are available.
Having these recipes available increases build time significantly and
increases the size of the SDK installer by 30-80 Mbytes depending on
how many recipes are included in your configuration.
</para>
<para>
You can use
<filename>EXCLUDE_FROM_WORLD_pn-</filename><replaceable>recipename</replaceable>
for recipes you want to exclude.
However, it is assumed that you would need to be building the "world"
target if you want to provide additional items to the SDK.
Consequently, building for "world" should not represent undue
overhead in most cases.
<note>
If you set <filename>SDK_EXT_TYPE</filename> to "minimal",
then providing a shared state mirror is mandatory so that items
can be installed as needed.
See the
"<link linkend='sdk-providing-additional-installable-extensible-sdk-content'>Providing Additional Installable Extensible SDK Content</link>"
section for more information.
</note>
</para>
</section>
</appendix> </appendix>
<!-- <!--

82
documentation/sdk-manual/sdk-appendix-obtain.xml
View File

@@ -52,18 +52,20 @@
<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 if you have a you can build the toolchain installer assuming you have first sourced
<ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>. the environment setup script.
<note> See the
Although not the preferred method, it is also possible to use "<ulink url='&YOCTO_DOCS_QS_URL;#qs-building-images'>Building Images</ulink>"
<filename>bitbake meta-toolchain</filename> to build the toolchain section in the Yocto Project Quick Start for steps that show you
installer. how to set up the Yocto Project environment.
If you do use this method, you must separately install and extract In particular, you need to be sure the
the target sysroot. <ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
For information on how to install the sysroot, see the variable matches the architecture for which you are building and that
"<link linkend='sdk-extracting-the-root-filesystem'>Extracting the Root Filesystem</link>" the
section. <ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
</note> variable is correctly set if you are building a toolchain designed to
run on an architecture that differs from your current development host
machine (i.e. the build machine).
</para> </para>
<para> <para>
@@ -80,54 +82,6 @@
that matches your target root filesystem. that matches your target root filesystem.
</para> </para>
<para>
Another powerful feature is that the toolchain is completely
self-contained.
The binaries are linked against their own copy of
<filename>libc</filename>, which results in no dependencies
on the target system.
To achieve this, the pointer to the dynamic loader is
configured at install time since that path cannot be dynamically
altered.
This is the reason for a wrapper around the
<filename>populate_sdk</filename> and
<filename>populate_sdk_ext</filename> archives.
</para>
<para>
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>
Remember, before using any BitBake command, you
must source the build environment setup script
(i.e.
<ulink url='&YOCTO_DOCS_REF_URL;#structure-core-script'><filename>&OE_INIT_FILE;</filename></ulink>
or
<ulink url='&YOCTO_DOCS_REF_URL;#structure-memres-core-script'><filename>oe-init-build-env-memres</filename></ulink>)
located in the Source Directory and you must make sure your
<filename>conf/local.conf</filename> variables are correct.
In particular, you need to be sure the
<ulink url='&YOCTO_DOCS_REF_URL;#var-MACHINE'><filename>MACHINE</filename></ulink>
variable matches the architecture for which you are building and that
the
<ulink url='&YOCTO_DOCS_REF_URL;#var-SDKMACHINE'><filename>SDKMACHINE</filename></ulink>
variable is correctly set if you are building a toolchain designed to
run on an architecture that differs from your current development host
machine (i.e. the build machine).
</para>
<para> <para>
When the <filename>bitbake</filename> command completes, the toolchain When the <filename>bitbake</filename> command completes, the toolchain
installer will be in installer will be in
@@ -154,12 +108,8 @@
<title>Extracting the Root Filesystem</title> <title>Extracting the Root Filesystem</title>
<para> <para>
After installing the toolchain or building it using BitBake, After installing the toolchain, for some use cases you
you need a root filesystem, which you need to separately extract. might need to separately extract a root filesystem:
</para>
<para>
Here are some cases where you need to extract the root filesystem:
<itemizedlist> <itemizedlist>
<listitem><para>You want to boot the image using NFS. <listitem><para>You want to boot the image using NFS.
</para></listitem> </para></listitem>

112
documentation/sdk-manual/sdk-extensible.xml
View File

@@ -540,39 +540,103 @@
</para> </para>
</section> </section>
<section id='sdk-using-the-extensible-sdk-to-task-2'> <section id='sdk-installing-additional-items-into-the-extensible-sdk'>
<title>Using the Extensible SDK to <replaceable>item-2</replaceable></title> <title>Installing Additional Items Into the Extensible SDK</title>
<para role='writernotes'> <para>
Describe the specific task you are going to accomplish with the The extensible SDK typically only comes with a small number of tools
extensible SDK. and libraries out of the box.
Provide a diagram showing the rough flow of the task. If you have a minimal SDK, then it starts mostly empty and is
Provide specific steps using a real example that works through the populated on-demand.
task. However, sometimes you will need to explicitly install extra items
into the SDK.
If you need these extra items, you can first search for the items
using the <filename>devtool search</filename> command.
For example, suppose you need to link to libGL but you are not sure
which recipe provides it.
You can use the following command to find out:
<literallayout class='monospaced'>
$ devtool search libGL
mesa A free implementation of the OpenGL API
</literallayout>
Once you know the recipe (i.e. <filename>mesa</filename> in this
example), you can install it:
<literallayout class='monospaced'>
$ devtool sdk-install mesa
</literallayout>
By default, the <filename>devtool sdk-install</filename> assumes the
item is available in pre-built form from your SDK provider.
If the item is not available and it is acceptable to build the item
from source, you can add the "-s" option as follows:
<literallayout class='monospaced'>
$ devtool sdk-install -s mesa
</literallayout>
It is important to remember that building the item from source takes
significantly longer than installing the pre-built artifact.
Also, if no recipe exists for the item you want to add to the SDK, you
must add it using the <filename>devtool add</filename> command.
</para> </para>
</section> </section>
<section id='sdk-using-the-extensible-sdk-to-task-3'> <section id='sdk-updating-the-extensible-sdk'>
<title>Using the Extensible SDK to <replaceable>item-3</replaceable></title> <title>Updating the Extensible SDK</title>
<para role='writernotes'> <para>
Describe the specific task you are going to accomplish with the If you are working with an extensible SDK that gets occasionally
extensible SDK. updated (e.g. typically when that SDK has been provided to you by
Provide a diagram showing the rough flow of the task. another party), then you will need to manually pull down those
Provide specific steps using a real example that works through the updates to your installed SDK.
task. </para>
<para>
To update your installed SDK, run the following:
<literallayout class='monospaced'>
$ devtool sdk-update
</literallayout>
The previous command assumes your SDK provider has set the default
update URL for you.
If that URL has not been set, you need to specify it yourself as
follows:
<literallayout class='monospaced'>
$ devtool sdk-update <replaceable>path_to_update_directory</replaceable>
</literallayout>
<note>
The URL needs to point specifically to a published SDK and not an
SDK installer that you would download and install.
</note>
</para> </para>
</section> </section>
<section id='sdk-using-the-extensible-sdk-to-task-x'> <section id='sdk-creating-a-derivative-sdk-with-additional-components'>
<title>Using the Extensible SDK to <replaceable>item-x</replaceable></title> <title>Creating a Derivative SDK With Additional Components</title>
<para role='writernotes'> <para>
Describe the specific task you are going to accomplish with the You might need to produce an SDK that contains your own custom
extensible SDK. libraries for sending to a third party (e.g., if you are a vendor with
Provide a diagram showing the rough flow of the task. customers needing to build their own software for the target platform).
Provide specific steps using a real example that works through the If that is the case, then you can produce a derivative SDK based on
task. the currently installed SDK fairly easily.
Use these steps:
<orderedlist>
<listitem><para>If necessary, install an extensible SDK that
you want to use as a base for your derivative SDK.
</para></listitem>
<listitem><para>Source the environment script for the SDK.
</para></listitem>
<listitem><para>Add the extra libraries or other components
you want by using the <filename>devtool add</filename>
command.
</para></listitem>
<listitem><para>Run the <filename>devtool build-sdk</filename>
command.
</para></listitem>
</orderedlist>
The above procedure takes the recipes added to the workspace and
constructs a new SDK installer containing those recipes and the
resulting binary artifacts.
The recipes go into their own separate layer in the constructed
derivative SDK, leaving the workspace clean and ready for you
to add your own recipes.
</para> </para>
</section> </section>

28
documentation/sdk-manual/sdk-intro.xml
View File

@@ -45,6 +45,34 @@
the Yocto Project build system. the Yocto Project build system.
</para> </para>
<para>
SDKs are completely self-contained.
The binaries are linked against their own copy of
<filename>libc</filename>, which results in no dependencies
on the target system.
To achieve this, the pointer to the dynamic loader is
configured at install time since that path cannot be dynamically
altered.
This is the reason for a wrapper around the
<filename>populate_sdk</filename> and
<filename>populate_sdk_ext</filename> archives.
</para>
<para>
Another feature for the SDKs 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>
Going beyond the actual SDK, the SDK development environment consists Going beyond the actual SDK, the SDK development environment consists
of the following: of the following: