diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml
index e0db037454..ba182acaf4 100644
--- a/documentation/dev-manual/dev-manual-common-tasks.xml
+++ b/documentation/dev-manual/dev-manual-common-tasks.xml
@@ -3603,10 +3603,11 @@
Additional Implementation Details
- Different packaging systems have different levels of native Multilib
- support.
- For the RPM Package Management System, the following implementation details
- exist:
+ Different packaging systems have different levels of
+ native Multilib support (i.e. support for the host build
+ machine).
+ For the RPM Package Management System, the following
+ implementation details exist:
A unique architecture is defined for the Multilib packages,
along with creating a unique deploy folder under
@@ -3823,7 +3824,8 @@
in the form generated by the build system.
- You must build several native tools:
+ You must build several native tools, which are tools
+ built to run on the build system:
$ bitbake parted-native dosfstools-native mtools-native
@@ -6375,8 +6377,9 @@
developers when building for multiple machines.
When you use the same TMPDIR for
multiple machine builds, the OpenEmbedded build system can
- reuse the existing native and often cross-recipes for
- multiple machines.
+ reuse the existing native (i.e. host system) and often
+ cross-recipes (i.e. nativesdk
+ for multiple machines.
Thus, build time decreases.
If
@@ -7583,6 +7586,7 @@
run the test suite by using a single command
such as make check.
However, the native make check
+ that runs on the host system
builds and runs on the same computer, while
cross-compiling requires that the package is built
on the host but executed on the target.
@@ -8169,7 +8173,8 @@
specific to or dependent on the target
architecture:
You can work around these attempts by using native
- tools to accomplish the same tasks, or
+ tools, which run on the host system,
+ to accomplish the same tasks, or
by alternatively running the processes under QEMU,
which has the qemu_run_binary
function.
diff --git a/documentation/dev-manual/dev-manual-start.xml b/documentation/dev-manual/dev-manual-start.xml
index db989b7bfa..9f349adcdd 100644
--- a/documentation/dev-manual/dev-manual-start.xml
+++ b/documentation/dev-manual/dev-manual-start.xml
@@ -341,14 +341,17 @@
- Using a pre-built binary is ideal for developing software applications to run on your
- target hardware.
- To do this, you need to be able to access the appropriate cross-toolchain tarball for
- the architecture on which you are developing.
- If you are using an SDK type image, the image ships with the complete toolchain native to
- the architecture.
- If you are not using an SDK type image, you need to separately download and
- install the stand-alone Yocto Project cross-toolchain tarball.
+ Using a pre-built binary is ideal for developing software
+ applications to run on your target hardware.
+ To do this, you need to be able to access the appropriate
+ cross-toolchain tarball for the architecture on which you are
+ developing.
+ If you are using an SDK type image, the image ships with the complete
+ toolchain native to the architecture (i.e. a toolchain designed to
+ run on the
+ SDKMACHINE).
+ If you are not using an SDK type image, you need to separately download
+ and install the stand-alone Yocto Project cross-toolchain tarball.
diff --git a/documentation/ref-manual/faq.xml b/documentation/ref-manual/faq.xml
index 08e0fb170b..3137639d9a 100644
--- a/documentation/ref-manual/faq.xml
+++ b/documentation/ref-manual/faq.xml
@@ -791,7 +791,7 @@
- The files provided by my -native recipe do
+ The files provided by my *-native recipe do
not appear to be available to other recipes.
Files are missing from the native sysroot, my recipe is
installing to the wrong place, or I am getting permissions
diff --git a/documentation/ref-manual/introduction.xml b/documentation/ref-manual/introduction.xml
index 57e4a25853..750d9c681c 100644
--- a/documentation/ref-manual/introduction.xml
+++ b/documentation/ref-manual/introduction.xml
@@ -450,7 +450,9 @@
$ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
During execution, a prompt appears that allows you to
- choose the installation directory.
+ choose the installation directory for these tools
+ designed to run on the target machine
+ (SDKMACHINE).
For example, you could choose the following:
/home/your-username/buildtools
@@ -530,7 +532,8 @@
On the machine that does not meet the requirements,
run the .sh file
- to install the tools.
+ to install the tools built to run on the target machine
+ (SDKMACHINE).
Here is an example:
$ sh poky-glibc-x86_64-buildtools-tarball-x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
diff --git a/documentation/ref-manual/migration.xml b/documentation/ref-manual/migration.xml
index 45ac041d92..62f792bf7b 100644
--- a/documentation/ref-manual/migration.xml
+++ b/documentation/ref-manual/migration.xml
@@ -97,13 +97,14 @@
The shared state cache (sstate-cache), as pointed to by
- SSTATE_DIR, by default
- now has two-character subdirectories to prevent issues arising
- from too many files in the same directory.
- Also, native sstate-cache packages will go into a subdirectory named using
+ SSTATE_DIR,
+ by default now has two-character subdirectories to prevent
+ issues arising from too many files in the same directory.
+ Also, native sstate-cache packages, which are built to run
+ on the host system, will go into a subdirectory named using
the distro ID string.
- If you copy the newly structured sstate-cache to a mirror location
- (either local or remote) and then point to it in
+ If you copy the newly structured sstate-cache to a mirror
+ location (either local or remote) and then point to it in
SSTATE_MIRRORS,
you need to append "PATH" to the end of the mirror URL so that
the path used by BitBake before the mirror substitution is
@@ -191,7 +192,9 @@
The suffix nativesdk is now implemented
as a prefix, which simplifies a lot of the packaging code for
nativesdk recipes.
- All custom nativesdk recipes and any
+ All custom nativesdk recipes, which are
+ recipes built on the host system to create packages for the
+ target machine, and any
references need to be updated to use
nativesdk-* instead of
*-nativesdk.
diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml
index 7ba9a9770f..f994a2269d 100644
--- a/documentation/ref-manual/ref-classes.xml
+++ b/documentation/ref-manual/ref-classes.xml
@@ -463,10 +463,11 @@
The chrpath class
- is a wrapper around the "chrpath" utility, which is used during the
- build process for nativesdk,
- cross, and
- cross-canadian recipes to change
+ is a wrapper around the "chrpath" utility.
+ This utility is used during the build process for
+ nativesdk, cross, and
+ cross-canadian recipes, which run on the host
+ system to create packages for the target hardware and change
RPATH records within binaries in order to make
them relocatable.
@@ -1146,8 +1147,8 @@
<filename>gzipnative.bbclass</filename>
- The gzipnative
- class enables the use of native versions of gzip
+ The gzipnative class enables the use of
+ different native versions of gzip
and pigz rather than the versions of these tools
from the build host.
diff --git a/documentation/ref-manual/ref-variables.xml b/documentation/ref-manual/ref-variables.xml
index 4ca4e51d5d..71f4ca680c 100644
--- a/documentation/ref-manual/ref-variables.xml
+++ b/documentation/ref-manual/ref-variables.xml
@@ -1396,15 +1396,22 @@
The bare name of the recipe.
- This variable is a version of the PN variable
- but removes common suffixes such as "-native" and "-cross" as well
- as removes common prefixes such as multilib's "lib64-" and "lib32-".
+ This variable is a version of the
+ PN
+ variable but removes common suffixes such as
+ -native and
+ -cross as well
+ as removes common prefixes such as multilib's
+ lib64- and
+ lib32-.
The exact list of suffixes removed is specified by the
- SPECIAL_PKGSUFFIX variable.
+ SPECIAL_PKGSUFFIX
+ variable.
The exact list of prefixes removed is specified by the
- MLPREFIX variable.
+ MLPREFIX
+ variable.
Prefixes are removed for multilib
- and nativesdk cases.
+ and nativesdk- cases.
@@ -1467,7 +1474,7 @@
Specifies the flags to pass to the C pre-processor
(i.e. to both the C and the C++ compilers) when building
for the build host.
- When building in the native context,
+ When building in the -native context,
CPPFLAGS
is set to the value of this variable by default.
@@ -1483,7 +1490,7 @@
Specifies the flags to pass to the C++ compiler when
building for the build host.
- When building in the native context,
+ When building in the -native context,
CXXFLAGS
is set to the value of this variable by default.
@@ -1558,7 +1565,7 @@
The OpenEmbedded build system uses the
BUILD_PREFIX value to set the
TARGET_PREFIX
- when building for native recipes.
+ when building for native recipes.
@@ -1839,7 +1846,7 @@
Specifies the flags to pass to the C compiler when building
for the SDK.
- When building in the nativesdk
+ When building in the nativesdk-
context,
CFLAGS
is set to the value of this variable by default.
@@ -1857,7 +1864,7 @@
Specifies the flags to pass to the C pre-processor
(i.e. to both the C and the C++ compilers) when building
for the SDK.
- When building in the nativesdk
+ When building in the nativesdk-
context,
CPPFLAGS
is set to the value of this variable by default.
@@ -1874,7 +1881,7 @@
Specifies the flags to pass to the C++ compiler when
building for the SDK.
- When building in the nativesdk
+ When building in the nativesdk-
context,
CXXFLAGS
is set to the value of this variable by default.
@@ -2031,7 +2038,7 @@
and then can be used as an override.
Here is an example where "python-native" is added to
DEPENDS
- only when building for the native case:
+ only when building for the -native case:
DEPENDS_append_class-native = " python-native"
@@ -2567,7 +2574,7 @@
BUILDSDK_CXXFLAGS
when building for an SDK (i.e.
- nativesdk)
+ nativesdk-)
@@ -4736,12 +4743,12 @@
BUILD_CC_ARCH
when building for the build host (i.e.
- native)
+ -native)
BUILDSDK_CC_ARCH
when building for an SDK (i.e.
- nativesdk)
+ nativesdk-)
@@ -11898,14 +11905,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
For recipes building for the target
machine, the value is "${STAGING_DIR}/${MACHINE}".
- For native
- recipes building
+ For native recipes building
for the build host, the value is empty given the
assumption that when building for the build host,
the build host's own directories should be used.
- For nativesdk
- recipes that build for the SDK, the value is
+ For native SDK
+ recipes that build for the SDK
+ (nativesdk), the value is
"${STAGING_DIR}/${MULTIMACH_HOST_SYS}".
@@ -12713,12 +12720,13 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
"${TARGET_SYS}-".
- For native recipes, the build
- system sets the variable to the value of
+ For native recipes, the build system sets the
+ variable to the value of
BUILD_PREFIX.
- For nativesdk recipes, the
+ For native SDK recipes
+ (nativesdk), the
build system sets the variable to the value of
SDK_PREFIX.
@@ -12757,9 +12765,8 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
Consider these two examples:
- Given a native recipe on a
- 32-bit, x86 machine running Linux, the value is
- "i686-linux".
+ Given a native recipe on a 32-bit, x86 machine
+ running Linux, the value is "i686-linux".
Given a recipe being built for a little-endian,
@@ -13365,11 +13372,14 @@ recipes-graphics/xorg-font/font-alias_1.0.3.bb:PR = "${INC_PR}.3"
toolchain set that runs on the
SDKMACHINE,
and each package should usually have the prefix
- "nativesdk-".
- When building an SDK using
- bitbake -c populate_sdk <imagename>,
- a default list of packages is set in this variable, but
- you can add additional packages to the list.
+ nativesdk-.
+ For example, consider the following command when
+ building an SDK:
+
+ $ bitbake -c populate_sdk imagename
+
+ In this case, a default list of packages is set in this
+ variable, but you can add additional packages to the list.
diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index 6b4deb3177..b4f6a832ed 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -470,17 +470,19 @@
- To complicate the problem, there are things that should not be included in
- the checksum.
+ To complicate the problem, there are things that should not be
+ included in the checksum.
First, there is the actual specific build path of a given task -
the WORKDIR.
- It does not matter if the work directory changes because it should not
- affect the output for target packages.
- Also, the build process has the objective of making native or cross packages relocatable.
- The checksum therefore needs to exclude WORKDIR.
+ It does not matter if the work directory changes because it should
+ not affect the output for target packages.
+ Also, the build process has the objective of making native
+ (build host) or cross packages (target hardware) relocatable.
+ The checksum therefore needs to exclude
+ WORKDIR.
The simplistic approach for excluding the work directory is to set
- WORKDIR to some fixed value and create the checksum
- for the "run" script.
+ WORKDIR to some fixed value and create the
+ checksum for the "run" script.