Please see the patch for bitbake for rationale. With this
setting in place, it's possible to set
OE_FRAGMENTS += "distro/poky machine/qemuarm"
and bitbake will interpret that as
DISTRO = "poky"
MACHINE = "qemuarm"
(From OE-Core rev: e959f916b4d2bb8af2e6a04116de9430bbde0c9f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When reviewing proposed fragments to add settings for DISTRO and MACHINE,
RP noted that such fragments only add clutter and overhead, and there's
no need to maintain them as separate files.
Rather when bitbake sees 'fragmentvar/fragmentvalue' it can expand that into
FRAGMENTVAR = "fragmentvalue".
To achieve that, 'addfragments' directive is extended with a parameter
that sets the name of the variable that holds definitions of such
built-in fragments, for example like this:
"machine:MACHINE distro:DISTRO"
Then each enabled fragment name is matched against these definitions and the
respective variable is set, e.g. 'machine/qemuarm' would match
'machine:MACHINE' and result in MACHINE set to 'qemuarm'.
This happens before any fragment files are looked up on disk,
and no such lookup happens if there was a match, which should prevent
possible misuse of the feature. So the builtin fragment definition
is also an allowlist for them.
Please also see the patches for oe-core that show an application of the feature.
(Bitbake rev: 3b9d7bea915dc7f10e845854f1dae325743f9456)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will allow setting the variable in oe-core such that it matches
S, which in turn will allow dropping S from almost all git:// fetching recipes,
and not having to set it in newly written ones.
(Bitbake rev: 378db0fdd95f8704fccd852452555bfddcad384d)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
get_bb_var() currently end up calling 'bitbake -e' and parsing the whole
output. However if postconfig isn't set then we can speed this up by
just calling bitbake-getvar.
The complication with failing bitbake-getvar calls is because we need to
be careful to return None instead of the empty string when the variable
doesn't exist.
(From OE-Core rev: fafe77879aa6225aa8b5187ff590bb4998cbf987)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the new TUNE_FEATURES to the 'features:' list, based on matching output
with:
rustc --target=riscv32i-unknown-none-elf -Ctarget-feature=help
Use the TUNE_RISCV_ABI instead of guessing for the ABI.
Pass the arch "as-is", since it should now be riscv32 or riscv64.
(From OE-Core rev: 88b59db87d2c65e5be0f3fee1ebf4ee64ef05f18)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This implements the following base ISAs:
* rv32i, rv64i
* rv32e, rv64i
The following ABIs:
* ilp32, ilp32e, ilp32f, ilp32d
* lp64, lp64e, lp64f, lp64d
The following ISA extension are also implemented:
* M - Integer Multiplication and Division Extension
* A - Atomic Memory Extension
* F - Single-Precision Floating-Point Extension
* D - Double-Precision Floating-Point Extension
* C - Compressed Extension
* B - Bit Manipulation Extension (implies Zba, Zbb, Zbs)
* V - Vector Operations Extension
* Zicsr - Control and Status Register Access Extension
* Zifencei - Instruction-Fetch Fence Extension
* Zba - Address bit manipulation extension
* Zbb - Basic bit manipulation extension
* Zbc - Carry-less multiplication extension
* Zbs - Single-bit manipulation extension
* Zicbom - Cache-block management extension
The existing processors tunes are preserved:
* riscv64 (rv64gc)
* riscv32 (rv32gc)
* riscv64nf (rv64imac_zicsr_zifencei)
* riscv32nf (rv32imac_zicsr_zifencei)
* riscv64nc (rv64imafd_zicsr_zifencei)
Previously defined feature 'big-endian' has been removed as it was not used.
(From OE-Core rev: bcaf298a146dfd10e4c8f44223ea083bc4baf45c)
Signed-off-by: Mark Hatle <mark.hatle@amd.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding documentation for the new feature to store in SPDX
only the compiled sources.
Merged in oe-core: c6a2f1fca76fae4c3ea471a0c63d0b453beea968
- spdx: add option to include only compiled sources
CC: Antonin Godard <antonin.godard@bootlin.com>
(From yocto-docs rev: 4dbc63ed1381fe47723d6ba5b7baf2a3b7fd19aa)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To accompany earlier updating of kernel version, update this lonely
reference to be consistent.
(From yocto-docs rev: e26c2018cd663de91ee08e0cba55eda1a4c30210)
Signed-off-by: "Robert P. J. Day" <rpjday@crashcourse.ca>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Let's specify that we are only expecting "absolute" paths in the docs
directive for local document referencing.
(From yocto-docs rev: 2729250bf1068814e5106d1e71796e8a505963d7)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This makes all :doc: directives use an absolute paths (with the root
directory being documentation/ in the repo).
This is then consistent across the whole source and is easier to review
and move files around, you just need to know where a file is located
relative to documentation/ directory and use that.
This gets rid of paths looking in parent directory with '..' as well as
expecting a file to be in the same directory as the other file it points
to via the :doc: directive.
(From yocto-docs rev: b9457f2005b0bea49c54e9727eb30e9458084886)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change the sample kernel version being used from 4.4 to a more modern
6.12.
(From yocto-docs rev: 1bad12b6ccfe1c0d26918926176a0c743568de26)
Signed-off-by: "Robert P. J. Day" <rpjday@crashcourse.ca>
Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The new ":doc:" reference for yocto-project-supported-features appears
to be missing a leading slash, causing HTML generation to fail.
(From yocto-docs rev: 4114399711ff82893a10c9eba0ff66c9af7b1c9e)
Signed-off-by: "Robert P. J. Day" <rpjday@crashcourse.ca>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In Sections 4.3.1 and 4.3.2 of the Overview Manual, a bit of tidying
including:
- provide full list of packaging options
- add monospaced rendering where appropriate
- fix broken "ref"
- make capitalization consistent
(From yocto-docs rev: 1cf769e3c8a8442cd05449dc97e91ad482d635f3)
Signed-off-by: "Robert P. J. Day" <rpjday@crashcourse.ca>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add migration documentation for users moving from the removed
kernel-fitimage.bbclass to the new kernel-fit-image.bbclass.
(From yocto-docs rev: 4c3552940a6ff89824845473317b7f5d741d4635)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit drops references to the kernel-fitimage.bbclass to prevent
from build errors when the label is no longer available.
(From yocto-docs rev: 3610cfd76d1491d9ecff9816ab36df8d1b2a83c6)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The nativesdk- prefix to the recipe filename should only be used when
using the inherit method as the BBCLASSEXTEND method will do some magic
when generating the "implicit" name of the recipe.
This matches the instructions for the native class.
(From yocto-docs rev: 15fe239e1e62b9add737aa732dd7f5e9948ee03d)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We explain how to create a native (nativesdk) recipe in two different
ways via a bullet list but reading quickly the instructions may mislead
one into doing both options whereas they are incompatible.
This rewords both the nativesdk and native sections so that the second
bullet point starts with an Or and explicit that this applies to target
recipes.
(From yocto-docs rev: 6d0d338a5f2686ddeee5eed7b6e05f3db800d33a)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
NVD ([1]) tracks this as:
cpe:2.3🅰️golang:go:*:*:*:*:*:*:*:*
Running on/with
cpe:2.3⭕microsoft:windows:-:*:*:*:*:*:*:*
Yocto cve-check ignores the "Running on/with", so it needs to be ignored
explicitly.
[1] https://nvd.nist.gov/vuln/detail/CVE-2024-3566
(From OE-Core rev: c8ce6710d864d237fdf67d2c3d3aa0f0970a2a05)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Changelog for 8.4.0: https://docs.pytest.org/en/stable/changelog.html#pytest-8-4-0-2025-06-02
Add colorama (moved to oe-core from meta-python) and pygments to
RDEPENDS.
Note that 8.4.0 accidentally removed pytest.PytestReturnNotNoneWarning,
which seems to have broken some tests (e.g. python3-pytz). See:
https://github.com/pytest-dev/pytest/releases/tag/8.4.1
(From OE-Core rev: 908c5535506592af654e7efac5b4a28a05da23f6)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are a small number of these that are out of place, so re-sort the
entire list to clean it up.
(From OE-Core rev: 76d681c4b17c9169238c571bae7e25df2040960c)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add existing recipe from meta-python, since pytest lists it as a
dependency. This also puts it in maintainers.inc with myself as
maintainer.
[RP: Switch to use hatching directly]
(From OE-Core rev: 8c06239fdcf983dac759c7d80d6326807c993622)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a basic test for the toolchain switching code: set the
toolchain to GCC by default but Clang for a specific recipe, and verify
that two recipes are built with the expected compiler.
This works because before we strip the installed binaries there is a
.comment segment that contains the list of toolchains used.
(From OE-Core rev: 7988c32191927f1c6db422c959eab7a03dfeda04)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Discovered when looking for users of get_bb_var()'s postconfig argument,
this wrapper around runCmd() has a postconfig argument that has odd
behaviour: it _appends_ the new configuration to local.conf instead of
having them used for this specific run (unlike the other functions in
commands.py)
None of the eSDK tests use this functionality, so remove it. Future test
cases that need to write further configuration should do so directly.
(From OE-Core rev: 6196d096b95b36f8b72b4049d5479f8f23e7891d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I can't see a reason for this script to need to use postconfig files
to bounce a variable assignment through another, so remove them.
(From OE-Core rev: 4a919459feb90ab8a8b9d10381486b77ad5aec52)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ctest automatically optimizes the order of (parallel) test execution based on
historic test case runtime via the COST property (see [0]), which can have a
significant impact on overall test run times. Sadly this feature is broken in
CMake < 4.0.0 for test cases that have spaces in their name (see [1]).
This commit backports the upstream fix. As repeated test runs are expected to
mainly take place inside the SDK, the patch is only applied to 'nativesdk'
builds.
[0]: https://cmake.org/cmake/help/latest/prop_test/COST.html
[1]: https://gitlab.kitware.com/cmake/cmake/-/issues/26594
Reported-By: John Drouhard <john@drouhard.dev>
(From OE-Core rev: dcbaf42dd74cc0bda7254856589613718ed3f057)
Signed-off-by: Moritz Haase <Moritz.Haase@bmw.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change enable-x11-forwarding PACKAGECONFIG to x11, while we can rely
directly on X11 DISTRO_FEATURE. Previously when enable-x11-forwarding was
used, the XAUTH_COMMAND failed due to missing xauth. So add xauth to
runtime recommends dependency and enable this behavior as default.
(From OE-Core rev: f0d2374b94a0e5d60ceed17998cd97f85b0486f6)
Signed-off-by: Andrej Valek <andrej.v@skyrain.eu>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If start-of-line is not enforced, then bogus tag 'gstreamer-sharp-1.13.0.1' would
match as 13.0.1.
(From OE-Core rev: 094cbd4f6a9f57eb146207355a921eaae44012ab)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds a new selftest case `test_sign_uboot_fit_image_without_spl` to verify
that the build can correctly generate and sign a U-Boot FIT image in a scenario
where no SPL is used.
Background:
- Some boards build only the U-Boot proper FIT image and do not require an SPL.
- The signing flow must handle this case gracefully: generate the ITS, sign
the FIT image, and skip signing/injecting a key into the SPL DTB.
What this test does:
1) Enables `UBOOT_FITIMAGE_ENABLE` and `SPL_SIGN_ENABLE` but explicitly sets
`SPL_DTB_BINARY` to an empty string to indicate that no SPL is present.
2) Verifies that the U-Boot ITS and FIT image are built successfully.
3) Confirms that the generated ITS file includes signature metadata as requested.
4) Dumps the FIT image to ensure that the signature nodes exist.
5) Confirms that the log for `do_uboot_assemble_fitimage` shows the expected
mkimage/mkimage_sign invocation.
This ensures that signing works correctly even when only the U-Boot proper is built,
which matches real-world configurations that do not require an SPL.
(From OE-Core rev: cdb4f4249a386113bebc65918a1b088c64e59182)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit cleans up and modernizes the shell condition expressions in
`uboot-sign.bbclass` to follow best practices for portable and reliable shell usage.
Key changes:
- Replace legacy `[ -a ]` and `[ -o ]` with explicit `[ ] && [ ]` and `[ ] || [ ]`.
Modern POSIX and busybox sh recommend using `&&` and `||` instead of `-a` and `-o`
because `-a` and `-o` are less robust and can cause parsing ambiguities in some shells.
- Simplify `concat_dtb()` by moving the DTB existence check to the top and using
early `return` to avoid deep nesting.
- Remove redundant fallback `else` blocks; use clearer control flow with direct checks.
This improves maintainability, reduces shell syntax pitfalls, and aligns with
current shell scripting best practices.
References:
- POSIX recommends avoiding `-a` and `-o` in `[ ]` and using explicit `&&` and `||`:
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html
(From OE-Core rev: d2740e39800a044d557b620e38ca0ac1b8c6d030)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously, the signing flow in "uboot-sign.bbclass" assumed that SPL was always
present and that the FIT signing process must inject the public key into the
SPL DTB. This made it inflexible for use cases where only the U-Boot proper
FIT image is built and signed, with no SPL binary at all.
This change introduces the following adjustments:
- The `SPL_DTB_BINARY` variable can be explicitly set to an empty string
to indicate that no SPL is present.
- The signing logic checks `SPL_DTB_BINARY` and skips injecting the
key or verifying the SPL DTB if it is empty.
- The FIT image generation and deployment are always performed if
`UBOOT_FITIMAGE_ENABLE` is enabled, regardless of the SPL settings.
- The deploy helper now uses a single check on `SPL_DTB_BINARY` to decide
whether to deploy the signed SPL DTB.
Now the sign step checks if SPL_DTB_BINARY is empty:
If present, it signs the FIT image and injects the public key into the SPL DTB,
then verifies both.
If empty, it only signs the FIT image and generates the ITS with the signature
node, but does not attempt to verify or add the key to a non-existent SPL DTB.
Key Behavior Explained
If SPL_DTB_BINARY is empty, we assume there is no SPL.
If UBOOT_FITIMAGE_ENABLE=1, we always create the FIT image and ITS.
If SPL_SIGN_ENABLE=1, we always sign the FIT image, but only inject the key into
the SPL DTB if it exists.
Example usage:
UBOOT_FITIMAGE_ENABLE = "1"
SPL_SIGN_ENABLE = "1"
SPL_DTB_BINARY = ""
This means:
- Generate and sign the FIT image.
- Do not attempt to sign or deploy an SPL DTB.
This aligns the implementation with real scenarios where some boards do not
require an SPL.
(From OE-Core rev: 7ad6acd8841752a5b75b8e2666bca5b609347cc1)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Install libpng test-suite to run it as a ptest.
As the test-suite takes more than 30 seconds to run,
add libpng-ptest to PTESTS_SLOW in ptest-packagelists.inc
(From OE-Core rev: 8dca5305c950e6a06b3f344ffdbbb7386d802095)
Signed-off-by: Poonam Jadhav <poonam.jadhav@kpit.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Adding postprocessing script to process data from linux CNA that includes more accurate metadata and it is updated directly by the source.
Example of enhanced CVE from a report from cve-check:
{
"id": "CVE-2024-26710",
"status": "Ignored",
"link": "https://nvd.nist.gov/vuln/detail/CVE-2024-26710",
"summary": "In the Linux kernel, the following vulnerability [...]",
"scorev2": "0.0",
"scorev3": "5.5",
"scorev4": "0.0",
"modified": "2025-03-17T15:36:11.620",
"vector": "LOCAL",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"detail": "not-applicable-config",
"description": "Source code not compiled by config. ['arch/powerpc/include/asm/thread_info.h']"
},
And same from a report generated with vex:
{
"id": "CVE-2024-26710",
"status": "Ignored",
"link": "https://nvd.nist.gov/vuln/detail/CVE-2024-26710",
"detail": "not-applicable-config",
"description": "Source code not compiled by config. ['arch/powerpc/include/asm/thread_info.h']"
},
For unpatched CVEs, provide more context in the description:
Tested with 6.12.22 kernel
{
"id": "CVE-2025-39728",
"status": "Unpatched",
"link": "https://nvd.nist.gov/vuln/detail/CVE-2025-39728",
"summary": "In the Linux kernel, the following vulnerability has been [...],
"scorev2": "0.0",
"scorev3": "0.0",
"scorev4": "0.0",
"modified": "2025-04-21T14:23:45.950",
"vector": "UNKNOWN",
"vectorString": "UNKNOWN",
"detail": "version-in-range",
"description": "Needs backporting (fixed from 6.12.23)"
},
CC: Peter Marko <peter.marko@siemens.com>
CC: Marta Rybczynska <rybczynska@gmail.com>
(From OE-Core rev: e60b1759c1aea5b8f5317e46608f0a3e782ecf57)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't have a recipe for subunit in core (or any layer in the layer
index), and unfortunately a bug in the CMakeLists means that the native
build can detect subunit on the host (so host contamination) and only
half-enable it, so the build fails.
Take a patch from upstream's github to add an option for subunit, and
explicitly disable it.
(From OE-Core rev: 155f0f65fa0f08a4586d3c9a02976f43a10b08aa)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch is specific to the autotools build of libcheck, but we use
CMake now.
(From OE-Core rev: 98091331829bd88b57fef5b811a4117b8db16032)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When SPDX_INCLUDE_COMPILED_SOURCES is enabled, only include the
source code files that are used during compilation.
It uses debugsource information generated during do_package.
This enables an external tool to use the SPDX information to disregard
vulnerabilities that are not compiled.
As example, when used with the default config with linux-yocto, the spdx size is
reduced from 156MB to 61MB.
Tested with bitbake world on oe-core.
CC: Quentin Schulz <quentin.schulz@cherry.de>
CC: Joshua Watt <JPEWhacker@gmail.com>
CC: Peter Marko <peter.marko@siemens.com>
(From OE-Core rev: c6a2f1fca76fae4c3ea471a0c63d0b453beea968)
Signed-off-by: Daniel Turull <daniel.turull@ericsson.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Exein is a platinum member and has primary support
(https://www.yoctoproject.org/members).
(From yocto-docs rev: b13bccbf3fb1890ac428a396f8c5081057edf555)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
And mention the new supported features document.
Suggested-by: Robert P. J. Day <rpjday@crashcourse.ca>
(From yocto-docs rev: d852a2d20e876440a48a240ca68d5f440ef2cfbe)
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set the contact address for meta-arm.
(From yocto-docs rev: 8ad91366ed89204affef6a72bd403b0d0a4525fa)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Antonin Godard <antonin.godard@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
As currently written, the PREFERRED_PROVIDER entries don't work with multilib
since they are added after the manipulations by multilib_global at ConfigParsed
time. We therefore need to spell out the configs correctly for multilib.
To avoid variable overwritten warnings from the expansion, we then have to
expand out the nativesdk providers usng class overrides.
(From OE-Core rev: 1f69850b62d1e022055d0f3b93ad270c2980462e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change implements a toolchain selection mechanism. Selection is
made using a set of variables, primarily PREFERRED_TOOLCHAIN_TARGET which
defaults to gcc.
It uses the familiar name for toolchain e.g. "gcc" which selects GNU
compiler + binutils as default C/C++ toolchain or "clang" which will
use LLVM/Clang Compiler. Layers an add their own toolchain definitions
too.
There are also PREFERRED_TOOLCHAIN_NATIVE and PREFERRED_TOOLCHAIN_SDK
which will ulitmately allow selection of the toolchain used for the
native/cross and nativesdk/crosssdk compilers. This currently isn't
functional but is essential to the patch to ensure things are set
to the existing gcc support in those cases.
Users would most commonly want to set:
PREFERRED_TOOLCHAIN_TARGET ?= "clang"
in local.conf or other distro specific global configuration metadata.
It is also selectable at recipe scope, since not all packages are
buildable with either clang or gcc, a recipe can explicitly require
a given toolchain using the TOOLCAHIN variable, e.g. glibc can not
be built with clang therefore glibc recipe sets:
TOOLCHAIN = "gcc"
The TOOLCHAIN variable is distinct from the user preference so recipes
with specific requirements can be identified. This also allows different
polcies to be be specified for native/SDK cases in the future.
(From OE-Core rev: 45bdedd213aff8df3214b95ef2a8551c0abd93a0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
