linux/poky.git/meta/classes-recipe/kernel-arch.bbclass, branch master

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie

kernel-arch.bbclass: Do not use weak assignment for TOOLCHAIN

2025-05-01T13:22:53+00:00

If a distro sets TOOLCHAIN with ?= or = then it overrides this too, however, we demand GCC to be in there due to KERNEL_CC etal Make it hard assignment, it can still be overturned via a bbappend in that case it is intentional to use non-gcc compiler for kernel (From OE-Core rev: 307902aa05c4537cb34fffe768df1547fb6a12d8) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

bitbake.conf: Switch prefix mapping to use -ffile-prefix-map

2025-04-23T08:47:42+00:00

-ffile-prefix map is more comprehensive when it comes to reproducible builds and its superset of all prefix-mapping options in compilers This makes is cleaner and workable across gcc and clang, clang does not support -fcanon-prefix-map and it has to be explicitly omitted when using clang. There are lambdas generated in templates by clang which still get the absolute paths despite -fdebug-prefix-map, this helps with that as well. nasm is an outlier and we have fixed it by adding -fdebug-prefix-map option luckily we do not pass DEBUG_PREFIX_MAP to nasm, in all recipes which use nasm either pass -fdebug-prefix-map explicitly to nasm or they rewrite it to use nasm flags syntax. We have discussed this in past [1] [1] https://patchwork.yoctoproject.org/project/oe-core/patch/20230428032030.2047920-1-raj.khem@gmail.com/#10281 (From OE-Core rev: ff73fa7ef7666a6dbe34f15515bc3ab6e574c5b0) Signed-off-by: Khem Raj Cc: Jacob Kroon Cc: Martin Jansa Signed-off-by: Richard Purdie

kernel-arch: add macro-prefix-map in KERNEL_CC

2025-03-08T18:08:04+00:00

When building external modules, macros can include absolute names of kernel headers. The macro-prefix-map for the STAGING_KERNEL_DIR is currently missing. Add it in the same way as its done in bitbake.conf. This fixes reproducible builds and following build error: ERROR: cryptodev-module-1.14-r0 do_package_qa: QA Issue: File <..> cryptodev.ko <..> contains reference to TMPDIR [buildpaths] (From OE-Core rev: a741e11751bfb8f52be58cf51abeddca4559e5e9) Signed-off-by: Stefan Müller-Klieser Signed-off-by: Richard Purdie

kernel-arch: Simplify strip support

2024-02-13T13:51:41+00:00

I think these options to strip were added to mirror the other kernel commandline options. In the strip case, it breaks code such as runstrip() in package.py since only a single command with no options is supported. For that reason I find it unlikely anyone is using this. Drop the problematic variables. (From OE-Core rev: 0d1c5971cafc1b65c000a10f7620e6ba22b53c91) Signed-off-by: Richard Purdie

kernel-arch: use ccache only for compiler

2023-11-22T14:08:48+00:00

Attempting to use it with other tools is not beneficial, only with the compiler. Confirmation from ccache's maintainer [1]. [1] https://github.com/ccache/ccache/discussions/1346#discussioncomment-7616180 (From OE-Core rev: 47fa8d81083f1ef594f8fe6fcab3e227e9607b3f) Signed-off-by: Javier Tia Signed-off-by: Richard Purdie

kernel-arch: drop CCACHE from KERNEL_STRIP definition

2023-11-05T11:28:35+00:00

Building linux-yocto with ccache enabled results in the 'command not found' error, because kernel-yocto.bbclass passes the KERNEL_STRIP as a single value, whic is then interpreted as a command name. ERROR: Fatal errors occurred in subprocesses: [Errno 2] No such file or directory: 'ccache aarch64-linaro-linux-strip': Traceback (most recent call last): File "/home/lumag/Projects/RPB/build-rpb/conf/../../layers/openembedded-core/meta/lib/oe/utils.py", line 288, in run ret = self._target(*self._args, **self._kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fixes: 03973c8c1c93 ("kernel: Add kernel specific STRIP variable") (From OE-Core rev: 41f019afc41f800b622c46a6d7cf1beffc97716a) Signed-off-by: Dmitry Baryshkov Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

kernel: make LOCALVERSION consistent between recipes

2023-07-25T14:27:33+00:00

The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. (From OE-Core rev: b378eec156998eea55ba61e59103cb34fab0d07c) Signed-off-by: Bruce Ashfield Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

kernel: fix localversion in v6.3+

2023-07-12T15:50:45+00:00

During testing of the v6.4 reference kernel, it was noticed that on-target modules no longer matched the magic value of the running kernel. This was due to a different localversion in the cross built kernel and the scripts / resources created on target. This was due to changes in the setlocalversion script introduced in the v6.3 series. The .scmversion file is no longer used (or packaged) to inhibit the addition of a "+" (through querying of the git status of the kernel) or the setting of a local version. We recently introduced the KERNEL_LOCALVERSION variable to allow recipes to place a value in .scmversion, so we extend the use of that variable to kernel-arch.bbclass and use it to set the exported variable LOCALVERSION. We must do it at the kernel-arch level, as the variable must be exported in any kernel build to ensure that setlocalversion always correctly sets the localversion. (From OE-Core rev: 765b13b7305c8d2f222cfc66d77c02e6a088c691) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel: Add kernel specific STRIP variable

2023-06-19T12:18:56+00:00

strip can be coming from binutils or from llvm in some cases llvm-strip can fail on kernel Subprocess output:aarch64-yoe-linux-llvm-strip: error: Link field value 28 in section .rela.dyn is not a symbol table This helps in selecting which strip is used when building kernel (From OE-Core rev: 03973c8c1c93ddb1c8e05b773bfcc45aed73a99f) Signed-off-by: Khem Raj Cc: Bruce Ashfield Signed-off-by: Richard Purdie