linux/poky.git/meta/conf, branch styhead-5.1.3

tune-cortexa32: set tune feature as armv8a

2024-11-26T13:37:09+00:00

Cortexa32 is a 32-bit armv8a architecture processor, so set the tune feature as armv8a instead of aarch64 which is 64-bit armv8a architecture. It solves the following build error while compiling libgcc-initial and libssp-nonshared. -- snip -- aarch64-poky-linux-musl-gcc: error: unrecognized command-line option '-mfpu=neon' aarch64-poky-linux-musl-gcc: error: unrecognized command-line option '-mfloat-abi=hard' -- snip -- (From OE-Core rev: 19402b5e867616e26c0013402a3b9f32acb6d9fc) Signed-off-by: Jagadeesh Krishnanjanappa Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie (cherry picked from commit 3b898270aca62559dfa42ed71d296fe8a8b46a41) Signed-off-by: Steve Sakoman

gcc-source: Fix racing on building gcc-source-14.2.0 and lib32-gcc-source-14.2.0

2024-11-26T13:37:09+00:00

While enabling multilib, build gcc-source-14.2.0 and lib32-gcc-source-14.2.0 at the same time: $ MACHINE = "qemux86-64" $ require conf/multilib.conf $ MULTILIBS = "multilib:lib32" $ DEFAULTTUNE:virtclass-multilib-lib32 = "x86" $ bitbake gcc-source-14.2.0 lib32-gcc-source-14.2.0 ... $ cat tmp-glibc/work-shared/gcc-14.2.0-r0.vr2401/temp/log.task_order 20241012-064533.415426 do_recipe_qa (2688052): log.do_recipe_qa.2688052 20241012-064533.463783 do_recipe_qa (2688051): log.do_recipe_qa.2688051 20241012-064533.805164 do_fetch (2688257): log.do_fetch.2688257 20241012-064533.852955 do_fetch (2688256): log.do_fetch.2688256 20241012-064617.823714 do_unpack (2698542): log.do_unpack.2698542 20241012-064617.871730 do_unpack (2698541): log.do_unpack.2698541 ... There are two tasks for do_fetch, do_unpack and others, so there are race issues. Both of them have the same hardcode 'gcc' prefix in ${WORKDIR} and ${S}, explicitly disable lib32-gcc-source-14.2.0 for multilib Set gcc-source as BPN of gcc-source-14.2.0 (From OE-Core rev: 9609a7c9c6d809cc02480c3f12f8dd7c6f3fe9fc) Signed-off-by: Hongxu Jia Signed-off-by: Richard Purdie (cherry picked from commit 901c47877e0710af50639f688e0bfdb851b762b5) Signed-off-by: Steve Sakoman

bitbake.conf: Mark VOLATILE_TMP_DIR as obsolete

2024-10-29T12:51:03+00:00

This variable was removed in https://git.yoctoproject.org/poky/commit/?id=2f46b6f27dfa3a9d5ad177900fcecfe64c3536f1 ("bitbake.conf: drop VOLATILE_TMP_DIR, use FILESYSTEM_PERMS_TABLES instead") so ensure that distributions become aware that it no longer has any effect. (From OE-Core rev: ec032dd13a19e4d4a332f06ace87f1f02143c3b2) (From OE-Core rev: a2b419d123b76594879da740eb665397929f70e0) Signed-off-by: Niko Mauno Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake.conf: Mark VOLATILE_LOG_DIR as obsolete

2024-10-29T12:51:03+00:00

This variable was removed in https://git.yoctoproject.org/poky/commit/?id=2f8806deb7655b37d6f8d12ff54680d6acf7a298 ("bitbake.conf: drop VOLATILE_LOG_DIR, use FILESYSTEM_PERMS_TABLES instead") so ensure that distributions become aware that it no longer has any effect. (From OE-Core rev: a951a900ce459191a9796a7069a1d3b658dda88f) (From OE-Core rev: fe1d653d094f006509c8b2aee3eafc5118be1ab3) Signed-off-by: Niko Mauno Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake.conf: mark TCLIBCAPPEND as deprecated

2024-09-17T11:16:00+00:00

In oe-core ebcd355 TCLIBCAPPEND (a string that is appended to TMPDIR) was removed entirely. Warn if this is being set by the distro as it will no longer have any effect. (From OE-Core rev: 992ba784c168710328749fd61a0e2869df519dea) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

layer.conf: Drop scarthgap namespace from LAYERSERIES

2024-09-06T15:20:57+00:00

As we move to release, drop the scarthgap namespace and prepare for styhead. (From OE-Core rev: b4cf6d5236a3eacaf56ca2f805b006efac65b26c) Signed-off-by: Richard Purdie

conf/defaultsetup.conf: Drop TCLIBCAPPEND

2024-09-05T20:50:10+00:00

We've been able to run musl and glibc builds in the same TMPDIR for many years and a separate directory is not required. Most distros disable this value for that reason. Drop support for the variable to make it clear and easy for distros to be able to set multiconfigs which behave consistently for distros which do and don't clear it by dropping it entirely. (From OE-Core rev: ebcd355a32e2711263e22d9b45b502696ecbb4d2) Signed-off-by: Richard Purdie

bitbake.conf: DEBUG_PREFIX_MAP: add -fmacro-prefix-map for STAGING_DIR_NATIVE

2024-09-05T20:48:47+00:00

* the default STAGING_DIR_NATIVE starts with STAGING_DIR_HOST and the only difference is '-native' suffix at the end * this can lead into replacing STAGING_DIR_NATIVE path with just "-native" in FILE macros * I've noticed this by accident in python3-matplotlib where buildpaths QA warning was triggered only for lib32-python3-matplotlib and it was because pybind11 path to STAGING_DIR_NATIVE was mapped to only '-native/' in python3-matplotlib build (which doesn't trigger buildpaths QA and lib32-python3-matplotlib the macro path wasn't replaced at all, because of 'lib32-' prefix in: -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot= \ -fmacro-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/lib32-recipe-sysroot= \ -fdebug-prefix-map=/OE/build/oe-core/tmp-glibc/work/i586-oemllib32-linux/lib32-python3-matplotlib/3.7.2/recipe-sysroot-native= \ * more details in meta-python fix for lib32-python3-matplotlib: https://lists.openembedded.org/g/openembedded-devel/message/112074 * the order of *-prefix-map options still seems to be that the last one matching wins and this works with gcc and clang, see: https://reviews.llvm.org/D148975?id=516863 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109591 * some components might sometimes be built with -coverage and could use -fcoverage-prefix-map: https://reviews.llvm.org/D148757 or -fprofile-prefix-map: https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fprofile-prefix-map but will leave that to recipes which actually use -coverage for now (From OE-Core rev: 90dea34cb624af744a7d5deabdd5cbfb3c10db87) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie

testexport: support for executing tests over serial

2024-09-01T11:28:10+00:00

Uses TEST_SERIALCONTROL_CMD to open a serial connection to the target and execute commands. This is a drop in replacement for the ssh target, fully supporting the same API. Supported with testexport. To use, set the following in local.conf: - TEST_TARGET to "serial" - TEST_SERIALCONTROL_CMD to a shell command or script which connects to the serial console of the target and forwards that connection to standard input/output. - TEST_SERIALCONTROL_EXTRA_ARGS (optional) any parameters that must be passed to the serial control command. - TEST_SERIALCONTROL_PS1 (optional) A regex string representing an empty prompt on the target terminal. Example: "root@target:.*# ". This is used to find an empty shell after each command is run. This field is optional and will default to "root@{MACHINE}:.*# " if no other value is given. - TEST_SERIALCONTROL_CONNECT_TIMEOUT (optional) Specifies the timeout in seconds for the initial connection to the target. Defaults to 10 if no other value is given. The serial target does have some additional limitations over the ssh target. 1. Only supports one "run" command at a time. If two threads attempt to call "run", one will block until it finishes. This is a limitation of the serial link, since two connections cannot be opened at once. 2. For file transfer, the target needs a shell and the base32 program. The file transfer implementation was chosen to be as generic as possible, so it could support as many targets as possible. 3. Transferring files is significantly slower. On a 115200 baud serial connection, the fastest observed speed was 30kbps. This is due to overhead in the implementation due to decisions documented in #2 above. (From OE-Core rev: d817b27d73d29ba2beffa2e0a4e31a14dbe0f1bf) Signed-off-by: Andrew Oppelt Signed-off-by: Matthew Weber Signed-off-by: Chuck Wolber -- Tested with core-image-sato on real hardware. TEST_SERIALCONTROL_CMD was set to a bash script which connected with telnet to the target. Additionally tested with QEMU by setting TEST_SERIALCONTROL_CMD to "ssh -o StrictHostKeyChecking=no root@192.168.7.2". This imitates a serial connection to the QEMU instance. Steps: 1) Set the following in local.conf: - IMAGE_CLASSES += "testexport" - TEST_TARGET = "serial" - TEST_SERIALCONTROL_CMD="ssh -o StrictHostKeyChecking=no root@192.168.7.2" 2) Build an image - bitbake core-image-sato 3) Run the test export - bitbake -c testexport core-image-sato 4) Run the image in qemu - runqemu nographic core-image-sato 5) Navigate to the test export directory 6) Run the exported tests with target-type set to serial - ./oe-test runtime --test-data-file ./data/testdata.json --packages-manifest ./data/manifest --debug --target-type serial Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

abi-version/ssate: Bump to avoid systemd hash corruption issue

2024-09-01T10:05:20+00:00

Unfortunately some recent patches caused non-deterministic output. One input hash lead to both good and bad output and whilst that patch has been fixed, the problematic hash 'cross' linkage remains. Bump to a new sstate and hash equivalence version to avoid this and work from a clean slate. (From OE-Core rev: 639e42b9c14dff516688964dba4ab25bba7b8a55) Signed-off-by: Richard Purdie