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)
(From OE-Core rev: 58eb15cdc2dd95bf5eb0bed2a0f1c43bf29cf273)
Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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 <richard.purdie@linuxfoundation.org>
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 <dmitry.baryshkov@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in switching toolchains cleanly for kernel build
between gcc and clang
Currently, some kernels allow building with clang but not all
the distro might use clang as default system compiler but kernel
may demand gcc which is provided via KERNEL_* variables, however
kernel does use OBJCOPY at places during build and it maybe set
to use llvm objcopy when using clang. That should be a deliberate
setting when clang is used for kernel as well, otherwise it should
use binutils provided objcopy
(From OE-Core rev: 17b409f2fd97894e0943d13c2cb0d52abde647e3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently TOOLCHAIN is strictly set to gcc in kernel-arch.bbclass.
And this prevents any TOOLCHAIN changes for any kernel recipe.
This change makes TOOLCHAIN configurable as usual.
(From OE-Core rev: be1634fc35dcc81f0301d942064a6eed584e0704)
Signed-off-by: Alexey Smirnov <pyih.soft@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
