There is no need to have two assignments; also setting S from
UNPACKDIR (and not vice versa) is more logical as unpack
task comes first, and tasks that come after unpack use S to access
unpack results.
Also adjust reference test data in selftest/recipeutils to reflect changes in test recipes.
(From OE-Core rev: f64b7e5fb3181734c8dde87b27e872a026261a74)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Where recipes use S = ${WORKDIR}, change them to set UNPACKDIR to
a subdir of WORKDIR and make S point at this instead.
I've chosen not to force S into any standard UNPACKDIR we may pick in
future just so the S = UNPACKDIR case is clearly visible by the
directory naming under WORKDIR as that should aid usability.
(From OE-Core rev: d9328e3b0b062f0621de3d114584b44f384a1c02)
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>
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>
The definitions in linux-kernel-base are needed to ensure the generated headers
are consistent. This was a small step that was missing from the previous
changes to linux-kernel-base as both kernel-devsrc and make-mod-scripts
need this information defined consistently.
(From OE-Core rev: 0d79d4883f924cef0d0ba361506ad75d441b9721)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a pattern that several recipes need to break the dependency of ${PN}-dev
on ${PN}, most often as ${PN} may be be empty. Add a new variable to parameterise
this and allow it to be changed more easily.
(From OE-Core rev: a5b381c0f45c590a762647a9956a8f41e2e2315e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
An automated conversion using scripts/contrib/convert-spdx-licenses.py to
convert to use the standard SPDX license identifiers. Two recipes in meta-selftest
were not converted as they're that way specifically for testing. A change in
linux-firmware was also skipped and may need a more manual tweak.
(From OE-Core rev: ceda3238cdbf1beb216ae9ddb242470d5dfc25e0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The licenses were renamed to match their SPDX names, fix the
references in LIC_FILES_CHKSUM in OE-Core.
(From OE-Core rev: 9af48917cfe583d2db9e1e088c7e396fcf638949)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With kernel v5.8+ and gcc10 plugins, we can run into the following build error:
HOSTCXX -fPIC scripts/gcc-plugins/arm_ssp_per_task_plugin.o
In file included from
/home/pokybuild/yocto-worker/qemuarm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/10.1.0/plugin/include/gcc-plugin.h:28,
from
/home/pokybuild/yocto-worker/qemuarm/build/build/tmp/work-shared/qemuarm/kernel-source/scripts/gcc-plugins/gcc-common.h:7,
from
/home/pokybuild/yocto-worker/qemuarm/build/build/tmp/work-shared/qemuarm/kernel-source/scripts/gcc-plugins/arm_ssp_per_task_plugin.c:3:
/home/pokybuild/yocto-worker/qemuarm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/make-mod-scripts/1.0-r0/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/10.1.0/plugin/include/system.h:687:10:
fatal error: gmp.h: No such file or directory
687 | #include <gmp.h>
| ^~~~~~~
(From OE-Core rev: cb055446e0fe4771c8bd6122e79d43ef8db2e45b)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is a build break which rarely happens but is seen often enough
with 4.1 kernel based builds
/bin/sh: 1: scripts/basic/fixdep: Permission denied
scripts/Makefile.host:124: recipe for target 'scripts/dtc/srcpos.o' failed
make[3]: *** [scripts/dtc/srcpos.o] Error 126
this patch sequences the build targets so it can work reliably with
different kernel versions
Divide the target into scripts_basic scripts is not
strictly necessary and was simply what was used for
testing on kernel 4.1, which is quite an old kernel
perhaps just using scripts is sufficient, but it is not tested to not
known will cause the build race as seen above.
(From OE-Core rev: 55ac6e2d251287419138931aa0d0894cf1267787)
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>
Fixed do_configure error when use linux-dummy:
PREFERRED_PROVIDER_virtual/kernel = "linux-dummy"
/bin/sh: bison: command not found
Build make-mod-scripts doesn't make sense when use linux-dummy, but it breaks
"bitbake world", so add bison-native to DEPENDS to fix the problem.
(From OE-Core rev: 4301d533512669834282a6ba43ae8e266a79fe22)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Kernels which use tools/objtool can now fail when building external modules
due to objtool being missing, the generated files can also cause problems
for kernel-devsrc.
Ensure objtool is generated in make-mod-scripts by also calling
"make prepare".
For devsrc, delete the generated binaries since they'd be native
binaries and unsuitable for the target.
The oeqa kernel module tests also need to have the additional "make prepare"
step added.
(From OE-Core rev: 52fd2993784b4218f5df4f343e7da45d964df305)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now that we have recipe-specific-sysroots we don't need to exclude recipes from
world builds because they conflict with other recipes, as they'll all be built
with their own sysroots.
(From OE-Core rev: b2f3ac4d994a1921791f6bd0cdb3591586733694)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Newer kernels (4.14/v4.15+) have dependencies for the build of
modules (and hence external modules). Without these dependencies
explicitly in the build chain, you can end up with build failures like:
work-shared/qemux86/kernel-source/scripts/extract-cert.c:21:25: fatal
error: openssl/bio.h: No such file or directory
| #include <openssl/bio.h>
| ^
| compilation terminated.
| make[2]: *** [scripts/extract-cert] Error 1
| make[1]: *** [scripts] Error 2
To ensure that these headers are in place, and that the scripts use
our build environment flags, we add a dependency on openssl-native
and use oe_make to invoke the build.
Older kernels have no issues with the extra dependency, so there's no
need to make this conditional.
(From OE-Core rev: 916cb2029d3c97bf12ebf03832b9ba980451dbcf)
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove do_make_scripts() from module-base.bbclass and put
functionality in a recipe. This will build the scripts only
once instead of each time an external module is built.
[YOCTO #12228]
(From OE-Core rev: ea12c46fe8748fb6606c603d463075a8624e6563)
Signed-off-by: Joe Slater <jslater@windriver.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
