poky: subtree update:9d1b332292..2834c2f853
Alex Stewart (3):
opkg-utils: upgrade to version 0.4.5
opkg: upgrade to version 0.4.5
opkg: add QA check for openssl feed verification
Alexander Kanavin (37):
virglrenderer: explicitly depend on libgbm
elfutils: update 0.183 -> 0.185
libcap: update 2.49 -> 2.50
perl: split perl-cross into its own recipe
perl-cross: 1.3.5 -> 1.3.6
perl: update 5.32.1 -> 5.34.0
libgcrypt: upgrade 1.9.2 -> 1.9.3
erofs-utils: correct upstream version check
m4: correct ptest failures
ovmf: update 2021.02 -> 2021.05
apt: update 2.2.3 -> 2.2.4
util-linux: update 2.36.2 -> 2.37
cross-canadian: correct the location of pkg-config files
nettle: update 3.7.2 -> 3.7.3
glib-2.0: update 2.68.2 -> 2.68.3
meson: upgrade 0.58.0 -> 0.58.1
ell: upgrade 0.40 -> 0.41
erofs-utils: upgrade 1.2.1 -> 1.3
grub: upgrade 2.04+2.06~rc1 -> 2.06
gptfdisk: upgrade 1.0.7 -> 1.0.8
connman: update 1.39 -> 1.40
libksba: upgrade 1.5.1 -> 1.6.0
libnss-mdns: upgrade 0.15 -> 0.15.1
libwpe: upgrade 1.10.0 -> 1.10.1
puzzles: upgrade to latest revision
rng-tools: upgrade 6.12 -> 6.13
stress-ng: upgrade 0.12.09 -> 0.12.10
python3-magic: upgrade 0.4.23 -> 0.4.24
sudo: upgrade 1.9.7 -> 1.9.7p1
wpebackend-fdo: upgrade 1.8.4 -> 1.10.0
xkeyboard-config: upgrade 2.32 -> 2.33
bitbake.conf: enable debuginfod in native/nativesdk
gdb-cross: enable debuginfod
util-linux: backport a patch to address mkswap hangs
selftest: do not hardcode /tmp/sdk
glibc: do not enable memory tagging on aarch64 just yet
mesa: enable gallium intel drivers when building for x86
Alexandre Belloni (1):
runqemu: time the copy to tmpfs
Alexey Brodkin (3):
gcc: Fixes for ARC
gdb: Add native GDB support for ARC
gcc: Apply multilib fix to ARC as well
Alistair Francis (3):
recipes-bsp/opensbi: Disable FW_PIC
recipes-bsp/u-boot: Allow deploying the u-boot DTB
recipes-bsp/opensbi: Add support for specifying a device tree
Anders Wallin (1):
coreutils: remove NOSTAT_LEAF_OPTIMIZATION
Andrea Adami (1):
kernel.bbclass: fix do_sizecheck() comparison
Andreas Müller (19):
mesa: upgrade 21.1.1 -> 21.1.2
systemd: Add more ugly casts to fix build with musl
alsa-lib: upgrade 1.2.4 -> 1.2.5
alsa-plugins: upgrade 1.2.2 -> 1.2.5
alsa-tools: upgrade 1.2.2 -> 1.2.5
alsa-topology-conf: upgrade 1.2.4 -> 1.2.5
alsa-ucm-conf: upgrade 1.2.4 -> 1.2.5
alsa-utils(-scripts): upgrade 1.2.4 -> 1.2.5
libinput: upgrade 1.17.3 -> 1.18.0
xf86-input-libinput: upgrade 0.30.0 -> 1.0.1
epiphany: upgrade 40.1 -> 40.2
vala: upgrade 0.52.3 -> 0.52.4
p11-kit: upgrade 0.23.22 -> 0.23.24
xorgproto: upgrade 2021.4.99.1 -> 2021.4.99.2
mpg123: 1.27.2 -> 1.28.0
libx11: upgrade 1.7.1 -> 1.7.2
libx11: remove CPPFLAGS_FOR_BUILD += "-D_GNU_SOURCE"
libpcap: upgrade 1.10.0 -> 1.10.1
mesa: upgrade 21.1.2 -> 21.1.3
Bruce Ashfield (10):
linux-yocto/5.10: update to v5.10.42
linux-yocto/5.10: temporarily revert aufs
linux-yocto-dev: base AUTOREV on specified version
linux-yocto/5.4: update to v5.4.124
linux-yocto/5.10: restore aufs
linux-yocto/5.10: update to v5.10.43
linux-yocto/5.4: update to v5.4.125
linux-yocto/5.10: cgroup1: fix leaked context root causing sporadic NULL deref in LTP
btrfs-tools: include linux/const.h to fix build with 5.12+ headers
bsps/5.10: update to v5.10.43
Changqing Li (1):
libjpeg-turbo: fix do_compile error on arm
Chris Laplante (1):
bitbake: build: warn on setting noexec/nostamp/fakeroot flag to any value besides '1'
Daniel Wagenknecht (5):
ref-manual: variables: update examples refering to DEPLOY_DIR_IMAGE
ref-manual: variables: document IMGDEPLOYDIR
ref-manual: migration-2.2: add note about IMGDEPLOYDIR
ref-manual: variables: fixup example in IMAGE_CMD
ref-manual: variables: fixup class reference in IMAGE_MANIFEST
Joe Slater (1):
tcf-agent: change license to EPL/EDL
Joshua Watt (2):
classes/buildhistory: Add option to strip path prefix
classes/reproducible_build: Use atomic rename for SDE file
Justin Bronder (1):
populate_sdk_ext: copy BBMULTICONFIG files
Kai Kang (1):
valgrind: fix a typo
Khem Raj (14):
harfbuzz: Fix unused-variable warning
arch-armv4: Allow -march=armv4
ffmpeg: Link in libatomic on riscv32
libssp-nonshared: Use a different implementation for __stack_chk_fail
qemuriscv: Enable 4 core emulation
gcompat: Add recipe
musl: Do not package glibc loader
musl: Set UPSTREAM_CHECK_COMMITS
Revert "libgcc-initial: Do not build fp128 to decimal ppc functions"
qemu: Provide float128 via hwcaps2 on ppc64le
linuxloader: Be aware of riscv32 ldso
linuxloader.bbclass: Add entry for ppc64 LE glibc loader
gcompat: Create symlinks to glibc ldso locations
sdk: Enable do_populate_sdk with multilibs
Luca Boccassi (1):
systemd: install new sysext tool via systemd-extra-utils
Marcus Comstedt (1):
conf/machine-sdk: Add ppc64 SDK machine
Matt Spencer (1):
systemd-conf: Prevent systemd-network from managing veth interfaces
Michael Halstead (1):
releases: update to include 3.1.8
Michael Opdenacker (12):
bitbake: docs: Add BB_HASHSERVE definition to glossary
bitbake: doc: bitbake-user-manual: fix erroneous statement in glossary intro
manuals: fix epub export warnings
ref-manual: move migration guides to separate document
releases: clarify supported and outdated releases
releases: put release number after "Release Series"
sdk-manual: fix broken references
migration guides: remove index reference to BB_SETSCENE_VERIFY_FUNCTION2
manuals: fix issues related to trailing dots
sdk-manual: add missing quoting around "devtool upgrade"
sdk-manual: fix wrong word
sdk-manual: add missing index references
Ming Liu (2):
u-boot-tools: fix a mkimage signature issue
uboot-sign.bbclass: fix some install commands
Mingli Yu (2):
sysstat: make the service start automatically
boost: fix wrong type for mutex in regex v5
Nicolas Dechesne (3):
index: remove the link/section to 'mega manual' from main page
index: remove links to releases manual and index
index: split releases manuals and indexes into two sections in the tree
Paul Barker (2):
bitbake: asyncrpc: Add ping method
bitbake: asyncrpc: Reduce verbosity
Quentin Schulz (6):
docs: ref-manual: migration-3.0: remove reference to non-existing BB_SETSCENE_VERIFY_FUNCTION2
docs: ref-manual: variables: add missing links to terms glossary
bitbake: doc: user-manual: remove mentions to BBVERSIONS
bitbake: doc: user-manual: ref-manual: remove mentions to BB_SETSCENE_VERIFY_FUNCTION2
documentation: Makefile: turn warnings into errors by default
docs: replace ``FOO`` by :term:`FOO` where possible
Richard Purdie (11):
lttng-tools: upgrade 2.12.3 -> 2.12.4
qemurunner: Try to ensure mmap'd libs are paged in
qemurunner: Increase startup timeout 120 -> 300
build-appliance-image: Update to master head revision
test-manual: add initial reproducible builds documentation
test-manual: Add initial YP Compatible documentation
README: Tweak as the website isn't really new now
README: Move to using markdown as the format
perf: Use python3targetconfig to ensure we use target libraries
ltp: Reinstate 'hanging' tests for evaluation
README.poky: Formatting and content cleanup
Richard Weinberger (1):
Document erofs filesystem targets
Robert P. J. Day (2):
ref-manual: add SRCTREECOVEREDTASKS to variable glossary
ref-manual: add glossary entry for NON_MULTILIB_RECIPES
Ross Burton (11):
mx: remove from Openembedded Core
core-image-weston: remove Clutter examples
Remove Clutter and Cogl
oeqa: remove Clutter usage
meta-poky: remove clutter references
Remove Clutter references
gcc: enable branch protection by standard
image_types: add zsync conversions
avahi: apply fix for CVE-2021-3468
qemu: fix virtio vhost-user-gpu CVEs
gcc: replace gdb helper install revert with the upstream fix
Sakib Sajal (3):
oeqa/core/target/qemu.py: display contents of dumped files
oe-time-dd-test.sh: improve output formatting
oe-time-dd-test.sh: add iostat command
Saul Wold (1):
qemurunner: add second qmp port
Scott Weaver (1):
bitbake: fetch2: add check for empty SRC_URI hash string
Tim Orling (8):
maintainers.inc: update email address
python3-scons: upgrade 3.1.2 -> 4.1.0; simplify
python3-hypothesis: upgrade 6.13.7 -> 6.13.14
at-spi2-core: upgrade 2.40.1 -> 2.40.2
python3-importlib-metadata: upgrade 4.4.0 -> 4.5.0
python3-manifest: add statistics subpackage
python3-hypothesis: upgrade 6.13.14 -> 6.14.0
python3: skip tests requiring tools-sdk
Tony Battersby (1):
glibc: fix path to place zdump in the tzcode package
Tony Tascioglu (3):
valgrind: Improve non-deterministic ptest reliability
valgrind: remove buggy ptest from arm64
valgrind: Actually install list of non-deterministic ptests
hongxu (1):
nativesdk-libdnf: fix installed and not shipped files
wangmy (21):
cmake: upgrade 3.20.2 -> 3.20.3
mtools: upgrade 4.0.27 -> 4.0.29
python3-magic: upgrade 0.4.22 -> 0.4.23
less: upgrade 586 -> 589
python3-libarchive-c: upgrade 3.0 -> 3.1
diffoscope: upgrade 175 -> 177
dtc: upgrade 1.6.0 -> 1.6.1
git: upgrade 2.31.1 -> 2.32.0
gnutls: upgrade 3.7.1 -> 3.7.2
go: upgrade 1.16.4 -> 1.16.5
less: upgrade 589 -> 590
ethtool: upgrade 5.10 -> 5.12
m4: upgrade 1.4.18 -> 1.4.19
alsa-lib: upgrade 1.2.5 -> 1.2.5.1
alsa-utils: upgrade 1.2.5 -> 1.2.5.1
alsa-topology-conf: upgrade 1.2.5 -> 1.2.5.1
alsa-ucm-conf: upgrade 1.2.5 -> 1.2.5.1
blktrace: upgrade 1.2.0 -> 1.3.0
enchant2: upgrade 2.2.15 -> 2.3.0
librepo: upgrade 1.14.0 -> 1.14.1
createrepo-c: upgrade 0.17.2 -> 0.17.3
zangrc (1):
python3-pycairo: upgrade 1.20.0 -> 1.20.1
zhengruoqin (6):
python3-importlib-metadata: upgrade 4.3.0 -> 4.4.0
libogg: upgrade 1.3.4 -> 1.3.5
liburcu: upgrade 0.12.2 -> 0.13.0
libcomps: upgrade 0.1.16 -> 0.1.17
python3-dbusmock: upgrade 0.23.0 -> 0.23.1
nfs-utils: upgrade 2.5.3 -> 2.5.4
Signed-off-by: Andrew Geissler <geissonator@yahoo.com>
Change-Id: Iac124e214336beb9cab7fb3b67a6968d4e34d06f
diff --git a/poky/documentation/sdk-manual/appendix-customizing-standard.rst b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
index 90b6345..9bc70cf 100644
--- a/poky/documentation/sdk-manual/appendix-customizing-standard.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing-standard.rst
@@ -17,10 +17,10 @@
variables control the set of packages adding to the SDK.
If you want to add individual packages to the toolchain that runs on the
-host, simply add those packages to the ``TOOLCHAIN_HOST_TASK`` variable.
+host, simply add those packages to the :term:`TOOLCHAIN_HOST_TASK` variable.
Similarly, if you want to add packages to the default set that is part
of the toolchain that runs on the target, add the packages to the
-``TOOLCHAIN_TARGET_TASK`` variable.
+:term:`TOOLCHAIN_TARGET_TASK` variable.
Adding API Documentation to the Standard SDK
============================================
diff --git a/poky/documentation/sdk-manual/appendix-customizing.rst b/poky/documentation/sdk-manual/appendix-customizing.rst
index 67b49d9..44f4334 100644
--- a/poky/documentation/sdk-manual/appendix-customizing.rst
+++ b/poky/documentation/sdk-manual/appendix-customizing.rst
@@ -35,13 +35,13 @@
- Variables listed in
:term:`SDK_LOCAL_CONF_WHITELIST`
are included. Including a variable in the value of
- ``SDK_LOCAL_CONF_WHITELIST`` overrides either of the previous two
+ :term:`SDK_LOCAL_CONF_WHITELIST` overrides either of the previous two
filters. The default value is blank.
- Classes inherited globally with
:term:`INHERIT` that are listed in
:term:`SDK_INHERIT_BLACKLIST`
- are disabled. Using ``SDK_INHERIT_BLACKLIST`` to disable these
+ are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these
classes is the typical method to disable classes that are problematic
or unnecessary in the SDK context. The default value blacklists the
:ref:`buildhistory <ref-classes-buildhistory>`
@@ -74,11 +74,9 @@
is set using the "?=" operator. Consequently, you will need to
either define the entire list by using the "=" operator, or you
will need to append a value using either "_append" or the "+="
- operator. You can learn more about these operators in the "
- Basic Syntax
- " section of the BitBake User Manual.
-
- .
+ operator. You can learn more about these operators in the
+ ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax`"
+ section of the BitBake User Manual.
- If you have classes or recipes that add additional tasks to the
standard build flow (i.e. the tasks execute as the recipe builds as
@@ -95,7 +93,7 @@
- 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 the ``SDK_INHERIT_BLACKLIST``
+ disable the tasks, add the class to the :term:`SDK_INHERIT_BLACKLIST`
variable as described in the previous section.
- Generally, you want to have a shared state mirror set up so users of
@@ -128,8 +126,7 @@
.. note::
You must also reflect this change in the value used for the
- COREBASE_FILES
- variable as previously described.
+ :term:`COREBASE_FILES` variable as previously described.
Changing the Extensible SDK Installer Title
===========================================
@@ -142,12 +139,12 @@
By default, this title is derived from
:term:`DISTRO_NAME` when it is
-set. If the ``DISTRO_NAME`` variable is not set, the title is derived
+set. If the :term:`DISTRO_NAME` variable is not set, the title is derived
from the :term:`DISTRO` variable.
The
:ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
-class defines the default value of the ``SDK_TITLE`` variable as
+class defines the default value of the :term:`SDK_TITLE` variable as
follows::
SDK_TITLE ??= "${@d.getVar('DISTRO_NAME') or d.getVar('DISTRO')} SDK"
@@ -158,7 +155,7 @@
an example, assume you have your own layer for your distribution named
"meta-mydistro" and you are using the same type of file hierarchy as
does the default "poky" distribution. If so, you could update the
-``SDK_TITLE`` variable in the
+:term:`SDK_TITLE` variable in the
``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
form::
@@ -220,7 +217,7 @@
You can
change this default installation directory by specifically setting the
-``SDKEXTPATH`` variable.
+:term:`SDKEXTPATH` variable.
While there are several ways of setting this variable,
the method that makes the most sense is to set the variable in your
@@ -229,7 +226,7 @@
assume you have your own layer for your distribution named
"meta-mydistro" and you are using the same type of file hierarchy as
does the default "poky" distribution. If so, you could update the
-``SDKEXTPATH`` variable in the
+:term:`SDKEXTPATH` variable in the
``~/meta-mydistro/conf/distro/mydistro.conf`` file using the following
form::
@@ -270,8 +267,7 @@
SSTATE_MIRRORS = "file://.* http://example.com/some_path/sstate-cache/PATH"
- You can set the
- ``SSTATE_MIRRORS`` variable in two different places:
+ You can set the :term:`SSTATE_MIRRORS` variable in two different places:
- If the mirror value you are setting is appropriate to be set for
both the OpenEmbedded build system that is actually building the
@@ -284,18 +280,17 @@
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
- - Alternatively, if you just want to set the ``SSTATE_MIRRORS``
+ - Alternatively, if you just want to set the :term:`SSTATE_MIRRORS`
variable's value for the SDK alone, create a
``conf/sdk-extra.conf`` file either in your
:term:`Build Directory` or within any
- layer and put your ``SSTATE_MIRRORS`` setting within that file.
+ layer and put your :term:`SSTATE_MIRRORS` 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
- SSTATE_MIRRORS
- .
+ :term:`SSTATE_MIRRORS`
Minimizing the Size of the Extensible SDK Installer Download
============================================================
@@ -333,7 +328,7 @@
See the :term:`SDK_INCLUDE_PKGDATA` variable for additional information.
-Setting the ``SDK_INCLUDE_PKGDATA`` variable as shown causes the "world"
+Setting the :term:`SDK_INCLUDE_PKGDATA` 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
@@ -350,15 +345,15 @@
If you set
SDK_EXT_TYPE
to "minimal", then providing a shared state mirror is mandatory so
- that items can be installed as needed. See the "
- Providing Additional Installable Extensible SDK Content
- " section for more information.
+ that items can be installed as needed. See the
+ :ref:`sdk-manual/appendix-customizing:providing additional installable extensible sdk content`
+ section for more information.
You can explicitly control whether or not to include the toolchain when
you build an SDK by setting the
:term:`SDK_INCLUDE_TOOLCHAIN`
variable to "1". In particular, it is useful to include the toolchain
-when you have set ``SDK_EXT_TYPE`` to "minimal", which by default,
+when you have set :term:`SDK_EXT_TYPE` to "minimal", which by default,
excludes the toolchain. Also, it is helpful if you are building a small
SDK for use with an IDE or some other tool where you do not want to take
extra steps to install a toolchain.
diff --git a/poky/documentation/sdk-manual/extensible.rst b/poky/documentation/sdk-manual/extensible.rst
index 55bd7f6..5520a07 100644
--- a/poky/documentation/sdk-manual/extensible.rst
+++ b/poky/documentation/sdk-manual/extensible.rst
@@ -15,9 +15,8 @@
.. note::
For a side-by-side comparison of main features supported for an
- extensible SDK as compared to a standard SDK, see the "
- Introduction
- " section.
+ extensible SDK as compared to a standard SDK, see the
+ :ref:`sdk-manual/intro:introduction` section.
In addition to the functionality available through ``devtool``, you can
alternatively make use of the toolchain directly, for example from
@@ -89,9 +88,9 @@
.. note::
As an alternative to downloading an SDK, you can build the SDK
- installer. For information on building the installer, see the "
- Building an SDK Installer
- " section.
+ installer. For information on building the installer, see the
+ :ref:`sdk-manual/appendix-obtain:building an sdk installer`
+ section.
The SDK and toolchains are self-contained and by default are installed
into the ``poky_sdk`` folder in your home directory. You can choose to
@@ -439,7 +438,7 @@
With this scenario, there is no ``srctree`` argument. Consequently, the
default behavior of the ``devtool modify`` command is to extract
- the source files pointed to by the ``SRC_URI`` statements into a
+ the source files pointed to by the :term:`SRC_URI` statements into a
local Git structure. Furthermore, the location for the extracted
source is the default area within the ``devtool`` workspace. The
result is that the command sets up both the source code and an
@@ -447,7 +446,7 @@
original location.
Additionally, if you have any non-patch local files (i.e. files
- referred to with ``file://`` entries in ``SRC_URI`` statement
+ referred to with ``file://`` entries in :term:`SRC_URI` statement
excluding ``*.patch/`` or ``*.diff``), these files are copied to
an ``oe-local-files`` folder under the newly created source tree.
Copying the files here gives you a convenient area from which you
@@ -477,7 +476,7 @@
devtool
command.
- As with all extractions, the command uses the recipe's ``SRC_URI``
+ As with all extractions, the command uses the recipe's :term:`SRC_URI`
statements to locate the source files and any associated patch
files. Non-patch files are copied to an ``oe-local-files`` folder
under the newly created source tree.
@@ -604,11 +603,11 @@
.. note::
Several methods exist by which you can upgrade recipes -
- devtool upgrade
+ ``devtool upgrade``
happens to be one. You can read about all the methods by which you
- can upgrade recipes in the "
- Upgrading Recipes
- " section of the Yocto Project Development Tasks Manual.
+ can upgrade recipes in the
+ :ref:`dev-manual/common-tasks:upgrading recipes` section
+ of the Yocto Project Development Tasks Manual.
The ``devtool upgrade`` command is flexible enough to allow you to
specify source code revision and versioning schemes, extract code into
@@ -656,18 +655,18 @@
don't use "-V", the command upgrades the recipe to the latest
version.
- If the source files pointed to by the ``SRC_URI`` statement in the
+ If the source files pointed to by the :term:`SRC_URI` statement in the
recipe are in a Git repository, you must provide the "-S" option and
specify a revision for the software.
- Once ``devtool`` locates the recipe, it uses the ``SRC_URI`` variable
+ Once ``devtool`` locates the recipe, it uses the :term:`SRC_URI` variable
to locate the source code and any local patch files from other
developers. The result is that the command sets up the source code,
the new version of the recipe, and an append file all within the
workspace.
Additionally, if you have any non-patch local files (i.e. files
- referred to with ``file://`` entries in ``SRC_URI`` statement
+ referred to with ``file://`` entries in :term:`SRC_URI` statement
excluding ``*.patch/`` or ``*.diff``), these files are copied to an
``oe-local-files`` folder under the newly created source tree.
Copying the files here gives you a convenient area from which you can
@@ -677,7 +676,7 @@
2. *Resolve any Conflicts created by the Upgrade*: Conflicts could happen
after upgrading the software to a new version. Conflicts occur
- if your recipe specifies some patch files in ``SRC_URI`` that
+ if your recipe specifies some patch files in :term:`SRC_URI` that
conflict with changes made in the new version of the software. For
such cases, you need to resolve the conflicts by editing the source
and following the normal ``git rebase`` conflict resolution process.
@@ -833,7 +832,7 @@
is not available. For cases where the dependency is not available, you
must use the ``devtool add`` command to add an additional recipe that
satisfies the dependency. Once you add that recipe, you need to update
-the ``DEPENDS`` variable in the original recipe to include the new
+the :term:`DEPENDS` variable in the original recipe to include the new
recipe.
If you need to add runtime dependencies, you can do so by adding the
@@ -862,7 +861,7 @@
:term:`LICENSE` value accordingly.
You should double-check the value added by the command against the
documentation or source files for the software you are building and, if
-necessary, update that ``LICENSE`` value.
+necessary, update that :term:`LICENSE` value.
The ``devtool add`` command also sets the
:term:`LIC_FILES_CHKSUM`
@@ -870,16 +869,16 @@
that license statements often appear in comments at the top of source
files or within the documentation. In such cases, the command does not
recognize those license statements. Consequently, you might need to
-amend the ``LIC_FILES_CHKSUM`` variable to point to one or more of those
-comments if present. Setting ``LIC_FILES_CHKSUM`` is particularly
+amend the :term:`LIC_FILES_CHKSUM` variable to point to one or more of those
+comments if present. Setting :term:`LIC_FILES_CHKSUM` is particularly
important for third-party software. The mechanism attempts to ensure
correct licensing should you upgrade the recipe to a newer upstream
version in future. Any change in licensing is detected and you receive
an error prompting you to check the license text again.
If the ``devtool add`` command cannot determine licensing information,
-``devtool`` sets the ``LICENSE`` value to "CLOSED" and leaves the
-``LIC_FILES_CHKSUM`` value unset. This behavior allows you to continue
+``devtool`` sets the :term:`LICENSE` value to "CLOSED" and leaves the
+:term:`LIC_FILES_CHKSUM` value unset. This behavior allows you to continue
with development even though the settings are unlikely to be correct in
all cases. You should check the documentation or source files for the
software you are building to determine the actual license.
@@ -905,7 +904,7 @@
hardcoding tools within the toolchain such as ``gcc`` and ``g++``.
- The environment in which Make runs is set up with various standard
- variables for compilation (e.g. ``CC``, ``CXX``, and so forth) in a
+ variables for compilation (e.g. :term:`CC`, :term:`CXX`, and so forth) in a
similar manner to the environment set up by the SDK's environment
setup script. One easy way to see these variables is to run the
``devtool build`` command on the recipe and then look in
@@ -921,7 +920,7 @@
the command line, add the variable setting to
:term:`EXTRA_OEMAKE` or
:term:`PACKAGECONFIG_CONFARGS`
- within the recipe. Here is an example using ``EXTRA_OEMAKE``::
+ within the recipe. Here is an example using :term:`EXTRA_OEMAKE`::
EXTRA_OEMAKE += "'CC=${CC}' 'CXX=${CXX}'"
@@ -1087,20 +1086,20 @@
:term:`EXTRA_OECONF` or
:term:`PACKAGECONFIG_CONFARGS`
set within the recipe. If you wish to pass additional options, add them
-to ``EXTRA_OECONF`` or ``PACKAGECONFIG_CONFARGS``. Other supported build
+to :term:`EXTRA_OECONF` or :term:`PACKAGECONFIG_CONFARGS`. Other supported build
tools have similar variables (e.g.
:term:`EXTRA_OECMAKE` for
CMake, :term:`EXTRA_OESCONS`
for Scons, and so forth). If you need to pass anything on the ``make``
-command line, you can use ``EXTRA_OEMAKE`` or the
+command line, you can use :term:`EXTRA_OEMAKE` or the
:term:`PACKAGECONFIG_CONFARGS`
variables to do so.
You can use the ``devtool configure-help`` command to help you set the
arguments listed in the previous paragraph. The command determines the
exact options being passed, and shows them to you along with any custom
-arguments specified through ``EXTRA_OECONF`` or
-``PACKAGECONFIG_CONFARGS``. If applicable, the command also shows you
+arguments specified through :term:`EXTRA_OECONF` or
+:term:`PACKAGECONFIG_CONFARGS`. If applicable, the command also shows you
the output of the configure script's "--help" option as a
reference.
@@ -1152,16 +1151,16 @@
subdirectory for each package. Apart from some advanced cases, the
:term:`PACKAGES` and
:term:`FILES` variables controls
-splitting. The ``PACKAGES`` variable lists all of the packages to be
-produced, while the ``FILES`` variable specifies which files to include
+splitting. The :term:`PACKAGES` variable lists all of the packages to be
+produced, while the :term:`FILES` variable specifies which files to include
in each package by using an override to specify the package. For
example, ``FILES_${PN}`` specifies the files to go into the main package
(i.e. the main package has the same name as the recipe and
``${``\ :term:`PN`\ ``}`` evaluates to the
-recipe name). The order of the ``PACKAGES`` value is significant. For
-each installed file, the first package whose ``FILES`` value matches the
-file is the package into which the file goes. Both the ``PACKAGES`` and
-``FILES`` variables have default values. Consequently, you might find
+recipe name). The order of the :term:`PACKAGES` value is significant. For
+each installed file, the first package whose :term:`FILES` value matches the
+file is the package into which the file goes. Both the :term:`PACKAGES` and
+:term:`FILES` variables have default values. Consequently, you might find
you do not even need to set these variables in your recipe unless the
software the recipe is building installs files into non-standard
locations.
diff --git a/poky/documentation/sdk-manual/working-projects.rst b/poky/documentation/sdk-manual/working-projects.rst
index ad84ce2..276daa9 100644
--- a/poky/documentation/sdk-manual/working-projects.rst
+++ b/poky/documentation/sdk-manual/working-projects.rst
@@ -135,9 +135,8 @@
To learn about environment variables established when you run the
cross-toolchain environment setup script and how they are used or
- overridden when the Makefile, see the "
- Makefile-Based Projects
- " section.
+ overridden by the Makefile, see the
+ :ref:`sdk-manual/working-projects:makefile-based projects` section.
This next command is a simple way to verify the installation of your
project. Running the command prints the architecture on which the
@@ -279,9 +278,9 @@
$ source /opt/poky/&DISTRO;/environment-setup-i586-poky-linux
3. *Create the Makefile:* For this example, the Makefile contains
- two lines that can be used to set the ``CC`` variable. One line is
+ two lines that can be used to set the :term:`CC` variable. One line is
identical to the value that is set when you run the SDK environment
- setup script, and the other line sets ``CC`` to "gcc", the default
+ setup script, and the other line sets :term:`CC` to "gcc", the default
GNU compiler on the build host::
# CC=i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux
@@ -298,7 +297,7 @@
4. *Make the Project:* Use the ``make`` command to create the binary
output file. Because variables are commented out in the Makefile, the
- value used for ``CC`` is the value set when the SDK environment setup
+ value used for :term:`CC` is the value set when the SDK environment setup
file was run::
$ make
@@ -307,10 +306,10 @@
i586-poky-linux-gcc -m32 -march=i586 --sysroot=/opt/poky/2.5/sysroots/i586-poky-linux main.o module.o -o target_bin
From the results of the previous command, you can see that
- the compiler used was the compiler established through the ``CC``
+ the compiler used was the compiler established through the :term:`CC`
variable defined in the setup script.
- You can override the ``CC`` environment variable with the same
+ You can override the :term:`CC` environment variable with the same
variable as set from the Makefile by uncommenting the line in the
Makefile and running ``make`` again.
::
@@ -334,7 +333,7 @@
variable as part of the command line. Go into the Makefile and
re-insert the comment character so that running ``make`` uses the
established SDK compiler. However, when you run ``make``, use a
- command-line argument to set ``CC`` to "gcc"::
+ command-line argument to set :term:`CC` to "gcc"::
$ make clean
rm -rf *.o