Building native Go tools results in the tool pointing to the wrong
location of dynamic linker (see below). The linker is looked up in the
temporary dir, which can be removed if rm_work is inherited. This
results in being unable to execute the program with the 'No such file or
directory' error. Override linker specificiation for native recipes (and
let Go build environment to pick up a correct one on it's own).
The error is observed in case the distro doesn't use uninative.bbclass.
If uninative.bbclass is used, the binary will be patched automatically
to use the uninative loader instead of the system one.
Without this patch:
$ ldd tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
linux-vdso.so.1 (0x00007ffe945ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3a7490e000)
/home/lumag/Projects/RPB/build-rpb/tmp-rpb-glibc/work/x86_64-linux/go-md2man-native/1.0.10+gitAUTOINC+f79a8a8ca6-r0/recipe-sysroot-native/usr/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f3a74d13000)
$ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man --help
-bash: tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man: No such file or directory
With the patch
$ ldd tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man
linux-vdso.so.1 (0x00007ffd19dbf000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2d44181000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2d44586000)
$ tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man --help
Usage of tmp-rpb-glibc/sysroots-components/x86_64/go-md2man-native/usr/bin/go-md2man:
-in string
Path to file to be processed (default: stdin)
-out string
Path to output processed file (default: stdout)
(From OE-Core rev: b611c77e4883ad81a8f40cbee3fea006500735ed)
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 44b397daa68b4d0a461225fe9ff7db8b5fcfdb7b)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When gos internal linker is used, it uses hardcoded paths to the
interpreter (dynamic linker). For x86_64 this hardcoded path is
/lib64/ld-linux-x86-64.so.2, but yocto's default dynamic linker path
is /lib64/ld-linux-x86-64.so.2.
Most of the time, the internal linker is not used and binutils linker
sets the correct path, but sometimes the internal linker is used and
the resulting binary will not work on x86_64.
To ensure the path is always correct, pass it to the linker.
(From OE-Core rev: 69128ca66991b13358f2552fcd5a7cfa6dda4952)
Signed-off-by: Joerg Vehlow <joerg.vehlow@aox.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6b54215074d7f3dbba07f096f16b9c0acf51527c)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If the kernel folder does not exist, find will result in an error.
This can occur if the kernel has no modules but, for example, custom modules are created.
Add check before deleting.
(From OE-Core rev: 4e4681b26e0d88ad219d72b75e598e6b81b430fc)
Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 7ef767d84d56b25498e45db83bb8f9d9caebeaf9)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If DROPBEAR_RSAKEY_DIR has already been set before, e.g. by overwriting
the file dropbear.default, the line will still be appended a second time.
DROPBEAR_RSAKEY_DIR="/path/to/dropbear"
DROPBEAR_EXTRA_ARGS="-B"
DROPBEAR_RSAKEY_DIR=/var/lib/dropbear
(Backport of rev: 6045314d29)
(From OE-Core rev: 8a502301209ef144932ef5071c1a9b738db23270)
Signed-off-by: Michael Glembotzki <Michael.Glembotzki@iris-sensing.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved
UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc
because it encodes ${PN} in it, which should be set by the U-Boot recipe.
Currently, whatever inherits uboot-config bbclass will fill-in its own PN,
which would change the content of UBOOT_INITIAL_ENV per-package.
Cc: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Cc: Marek Vasut <marex@denx.de>
Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations")
(From OE-Core rev: 18b76259d27dc045f621cd512582c37e8bbab45c)
Signed-off-by: Fabio Estevam <festevam@denx.de>
Backported from master: 0b0c4b37d318b86f100512476ffd861e0ce1f47e
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
[Backport cd2072e5d953 from the master without HOSTPKG_CONFIG setting]
The pkg-config workaround has been applied for kernel image building, but
not for module building. So pkg-config variables are different between
do_compile and do_compile_kernelmodules tasks. It may unnecessary trigger
rebuilding of a few host tools at the later task.
Especially when CONFIG_DEBUG_INFO_BTF is enabled in the kernel, it may even
trigger rebuilding vmlinux at do_compile_kernelmodules due to the rebuilt
host tools such as certs/extract-cert or objtool (on x86). This eventually
creates an inconsistent set of kernel binaries.
Here is the repro steps:
- Check out nanbield on x86
- The unexpected rebuild happens on kirkstone or possibly earlier
- Ensure that pahole is available (e.g. via meta-oe)
- Set KERNEL_DEBUG to "True" to properly set up PAHOLE
e.g.
$ export KERNEL_DEBUG="True"
$ export BB_ENV_PASSTHROUGH_ADDITIONS="${BB_ENV_PASSTHROUGH_ADDITIONS} KERNEL_DEBUG"
- Enable CONFIG_DEBUG_INFO_BTF=y
e.g.
$ bitbake -c menuconfig virtual/kernel
-> Kernel hacking
-> Compile-time checks and compiler options
-> Generate BTF typeinfo
- Build the kernel
e.g.
$ bitbake virtual/kernel
The BTF information in the resulting bzImage and kernel modules are
inconsistent, because the module's BTF information is generated using the
"second" vmlinux that doesn't have the identical BTF to the "first" vmlinux.
These modules can't be loaded at runtime due to the BTF mismatch.
This also leads to a build-id mismatch between the installed bzImage and
vmlinux since the bzImage is created from the first vmlinux, but the
installed vmlinux is the second one.
$ eu-readelf -n tmp/work/qemux86_64-poky-linux/linux-yocto/6.5.13+git/image/boot/{bzImage*,vmlinux*} | grep "Build ID"
Build ID: 4a0d62ee7fef0244950f0f604253729875bea493
Build ID: fb99b3d91399dbe42bf67ddee59e0f5a0c7f74d9
To avoid the unexpected rebuilding that results in such inconsistency, set
the same pkg-config variables when building kernel and modules. For kernel
5.19 and above, simply set the HOSTPKG_CONFIG in the make command line.
(From OE-Core rev: d63af11e92094487d6e358f27283e5385937e7a8)
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: cca0971a7d92d823cc0c2b16cf14a7b2ed8ecb61)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
cherry-picked from master b378eec156998eea55ba61e59103cb34fab0d07c
Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com>
Acked-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: 74897e505db19a23a5b864a48a4fa97d657605c8)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691
Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Just like UBOOT_LOCALVERSION, an end user can set KERNEL_LOCALVERSION
to append a string to the name of the local version of the kernel
image.
(From OE-Core rev: 29a0d2a49df8e24f3948a2ddf03743f0cb5d09dd)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
cherry-picked from master 229435a52f36ddec5f85fb6d5ccd42044b688397
Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
SafeConfigParser was renamed to ConfigParser in 3.2, and the
SafeConfigParser alias will be removed in 3.12.
(From OE-Core rev: 50815c328e677ac079d38dc8555a909f049cf5be)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cherry-picked from master: 71b3e7f71727137b4b996cc4160c9cc1581824b8
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This reverts commit d9273edae80978c34f8426f34f991b9598828aa9.
This commit is causing breakage for some vendor kernel builds.
(From OE-Core rev: 59cc2e75c15f8c6371a4c4a3b7bd2e6c3f145fbc)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
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: d9273edae80978c34f8426f34f991b9598828aa9)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cherry-picked from master 765b13b7305c8d2f222cfc66d77c02e6a088c691
Signed-off-by: Andreas Helbech Kleist <andreaskleist@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The task for fstypes with compression is the same as the task for the
uncompressed fstypes, e.g. when adding tar.xz to `IMAGE_FSTYPES`, it will
be included into the do_image_tar task and not creating a separate
do_image_tar.xz task.
This commit fixes `LIVE_ROOTFS_TYPE` with compressed fstypes by
depending on the actual task instead of the non-existent
do_image_<fstype>.<compression> task.
Fixes [YOCTO #15331]
(From OE-Core rev: 60d88989698968c13f8e641f0ba1a82fcf700fb7)
Signed-off-by: Ludovic Jozeau <ludovic.jozeau@smile.fr>
Reviewed-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 67c507e3d42e52a6d452c4a453eeaf7f2e2d68d6)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The target_dumper code is basically broken. It has been reading binary files
over the text base serial communication and runs at every command failure which
makes no sense. Each run might overwrite files from the previous run and the
output appears corrupted due to confusion from the binary data.
It isn't possible to cherry-pick "testimage: Drop target_dumper and most of monitor_dumper"
from master, so just make target_dumper, host_dumper, and monitor_dumper empty
functions.
For further details see:
https://lists.openembedded.org/g/openembedded-architecture/message/1888
(From OE-Core rev: 960e7e3dffa22c2142cb672c68cd9a8f0e3998a3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
wtmp is filled with binary data which the run_serial command can't cope with.
Catting this results in confusion of the serial interface and potentially large
backlogs of data in the buffers which can hang qemu.
Exclude the problematic files from the command.
(From OE-Core rev: 2afd9a6002cba2a23dd62a1805b4be04083c041b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 599ac08a6f6fb3f6a89a897c8e06367c63c2f979)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When SRCREV is used, call bb.fetch.get_srcrev() before accessing
SRC_URI. Without this new bb.fetch.get_srcrev() call, SRC_URI might be
accessed before SRCREV had a chance to be processed.
In master, this is fixed by https://git.yoctoproject.org/poky/commit/?id=62afa02d01794376efab75623f42e7e08af08526
However, this commit is not suited for backport since it is quite invasive.
The part of the commit that fix the bug is:
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -63,6 +63,7 @@ python () {
else:
d.setVar('B', '${WORKDIR}/${BPN}-${PV}')
+ bb.fetch.get_hashvalue(d)
local_srcuri = []
fetch = bb.fetch2.Fetch((d.getVar('SRC_URI') or '').split(), d)
for url in fetch.urls:
NB: bb.fetch.get_hashvalue() does not exist in kirkstone but is
equivalent to bb.fetch.get_srcrev().
Fixes [YOCTO #14918]
(From OE-Core rev: f6563cca6c4bf627e904d81fbe5b0b0f2b16a107)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Suggested-by: Chris Wyse <chris.wyse@wysechoice.net>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Some recipes reference these. Rather than continually trying to chase down the references
and taskhash issues, clear the variables for an easier life and simpler code. These
wouldn't convey anything useful in a native build.
(From OE-Core rev: 09ecafaf0e128c4dea062d359de37cbef461aed2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f8edeead263708889d31a7ff578ef8274cb678b4)
Signed-off-by: Jermain Horsman <jermain.horsman@nedap.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Machines that have added subdirectires to the KERNEL_DEVICETREE
recently, such as arm32 boards that were moved under subdirectories in
Linux 6.5, will have that subdirectory in the node name of the FIT. This
breaks existing systems that select a configuration in u-boot by it's
name.
Strip off the directory component from the device tree to preserve
compatibility.
(From OE-Core rev: 941ba1a132bafa9c9be855fb91fec96d8b06299f)
(From OE-Core rev: 9a42349a176ca4d7a1bfab3425a0821dbcbd9368)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> # backport to kirkstone
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Other spaces uses the Go architecture definitions as their own (for
example, container arches are defined to be Go arches). To make it
easier for other places to use this mapping, move the code that does the
translation of OpenEmbedded arches to Go arches to a library.
(From oe-core rev: 3e86f72fc2e1cc2e5ea4b4499722d736941167ce)
This commit together with meta-virtualization commit
115f6367f37095415f289fb6981cda9608ac72ff
broke meta-virtualization master used with
meta-lts-mixins kirkstone/go which is our primary
usecase for having kirkstone/go mixin layer
Manually crafted since cherry-pick had too many conflicts:
* different path to classes
* additional architecture loongarch64
* different way how to import library
(From OE-Core rev: 8726ae02d760270f9e7fe7ef5715d8f7553371ce)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Cc: Joshua Watt <JPEWhacker@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The JSON report generated by the cve-check class is basically a huge
list of packages. This list of packages is, however, unsorted.
To make things easier for people comparing the JSON, or more
specifically for git when archiving the JSON over time in a git
repository, we can sort the list by package name.
(From OE-Core rev: 1245649fd2725915154648a98584c908da07af18)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit e9861be0e5020830c2ecc24fd091f4f5b05da036)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Commit 4a4d5f78a6 ("package_rpm: use zstd
instead of xz") changed the rpm package compressor from 'xz' to 'zstd'
which results in decompression failure with BusyBox-provided 'rpm2cpio'
applet and 'rpm' applet when given the '-i' (Install package) option:
rpm2cpio: no gzip/bzip2/xz magic
Introduce a variable which makes it possible to use a different
compression mode, making it possible to override the default value for
example like
RPMBUILD_COMPMODE = "${@'w6T%d.xzdio' % int(d.getVar('XZ_THREADS'))}"
to enable rpm decompression without including the full rpm package in
the resulting root filesystem.
(From OE-Core rev: a40d9258148e28cbee2168c93179cd4c1232fb62)
(From OE-Core rev: ad4ea9f225b0dd6396088cc70b34f886c5fa62b4)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
uboot-extlinux-config allows to specify multiple "labels" (entries in a
menu, à-la grub) and each of them have their own values for some fields.
Each "base" variable, e.g. UBOOT_EXTLINUX_FDT can be overridden for each
label. This is done via the OVERRIDES mechanism based on the label name,
e.g. UBOOT_EXTLINUX_FDT:linux if linux is a label.
However, OVERRIDES doesn't contain the label globally because it's only
necessary in one task. Therefore, the OVERRIDES itself is modified
within the task. This means that the sigdata will not be told the
dependency on UBOOT_EXTLINUX_FDT:linux, because it cannot know about it.
For this reason, we need to explicitly specify which variables this task
depends on via vardeps varflag for the task.
This was done in the past, but we missed updating it during the override
syntax migration so the cache wouldn't get invalidated if someone
modifies UBOOT_EXTLINUX_FDT:linux from a configuration file or a
bbappend for example.
Let's fix this by migrating it to the new syntax.
(From OE-Core rev: 5570e49791b770271f176a4deeb5f6f1a028cb4a)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b4dd9d873508128adbbf5ff6cf0a3df3d2ffbcf6)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* this caused liberation-font-native to depend on TUNE_PKGARCH target fontconfig
because ${MLPREFIX}fontconfig-utils is added to RDEPENDS in anonymous python
* the dependency tree for liberation-font-native got much shorter
(just quilt-native and liberation-font-native itself):
2 after/pn-buildlist
78 before/pn-buildlist
* fixes graphviz-native signature issue as well as detected with sstate-diff-machines.sh
$ bitbake-diffsigs \
sstate-after/mako/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.184d4fd355f1e7a2d7d929ef4b5f62b94e2071df9dd674b2067ec21bfc7bcc1b \
sstate-after/qemux86-64/x86_64-linux/graphviz-native/8.1.0.do_populate_sysroot.sigdata.35da674d2dbc275bac02869dfce4165466315023910bdef65a6026e2cb942a46
Hash for task dependency liberation-fonts-native:do_populate_sysroot changed from 310d3da04ad9abf8ee99997e53d1ffa71c2b7d9d60fb0e8de85171a9ab6a77d3 to 048420ad1410c2b8d95498fc3c11681207335a2c722836f1f3e683cc449814da
(From OE-Core rev: 098d4ca85c2bc77949843f117c6e336d5b77271d)
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The latest 6.5 kernels do not appear to create the source file in
${D}${nonarch_base_libdir}/modules/${KERNEL_VERSION}/source so the
recipe errors out when trying to remove it. Simple fix is to add the
-f (force) flag to the call.
(From OE-Core rev: 2e669bf797b15d803e7d6a700e449bdc467a4bcc)
(From OE-Core rev: 7e177848f97eb9958619c28b5e5dadee12f67507)
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
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>
Variable overrides in KCONFIG_CONFIG_COMMAND do not work as expected due
to double quote mismatches. The issue is reproducible in an environment
where gold is the default linker. Below is an example snippet of
run.do_terminal generated by do_menuconfig.
do_terminal() {
exec sh -c "make menuconfig CC="aarch64-webos-linux-gcc ..."
LD="aarch64-webos-linux-ld.bfd ..."
...
}
Although LD override is set to bfd correctly, it is not passed to make
and make menuconfig ends up with messages like:
| gold linker is not supported as it is not capable of linking the kernel proper.
| scripts/Kconfig.include:56: Sorry, this linker is not supported.
(From OE-Core rev: 9c483765db762dbe8020423c8778518612b7e5f7)
(From OE-Core rev: 536c477838fb1a318c5b283475de7f0eac99c872)
Signed-off-by: Jaeyoon Jung <jaeyoon.jung@lge.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit d4664d2b79)
Backported: File was renamed between kirkstone and master.
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
cargo_do_compile runs only if the recipe is built using cargo
as the top level tool. Some recipes hide usage of cargo inside setuptools
(or autoconf) and use do_compile definitions specific to those,
and so the environment isn't properly set up.
This was exposed by latest versions of python3-cryptography.
(From OE-Core rev: a3f566fcbfc02e0a3b3f6a676d6dde88a5b50506)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9f4ff643a028d7f5670d80861f2ce19ca2d90faa)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Instead of deleting setscene tasks, now SSTATE_SKIP_CREATION is set instead.
This seems to fix the compile issues where the populate_sysroot task was
not run when an externalsrc recipe was built as a dependency.
[YOCTO #15164]
[RP addition: The deltask was added by me in 2012 when the class was created.
The trouble is bitbake assumes 'sstate' tasks have a setscene task and by deleting
the setscene task, bitbake stops thinking the task can be accelerated. There is other
code in the sysroot code which assumes some tasks are always sstate tasks.
We cannot delete the task without changes to the way bitbake learns about 'setscene'
tasks so the patch is correct, avoiding creating files is the better approach given
the way the world works now.
There would be concerns about exisitng sstate reuse however this shouldn't occur
since SRC_URI changes and that will change the underlying hashes. Hash equivalency
could potentially cause issues by joining hashes together again however if the output
matches, that shouldn't in theory cause any issue.]
(From OE-Core rev: f6bb8438a18dfa2a520ad6fa65662d908f4ef0ed)
Signed-off-by: Peter Suti <peter.suti@streamunlimited.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit ee4667a24ccdd8c9d547e73aecf661e6a1283890)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Due to an oversight in the do_symlink_kernsrc function, the path
comparison between "S" and "STAGING_KERNEL_DIR" is broken. The code
obtains both variables, but modifies the local copy of "S" before
comparing them, causing the comparison to always return false.
This can cause the build to fail when the EXTERNALSRC flag is enabled,
since the code will try to create a symlink even if one already exists.
This patch resolves the issue by comparing the variables before they are
modified.
(From OE-Core rev: cf2267f80ec44b24c627347df7efbd492a07dcfa)
Signed-off-by: Staffan Rydén <staffan.ryden@axis.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit afd2038ef8a66a5e6433be31a14e1eb0d9f9a1d3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Default search in meson would grok /usr/bin for llvm-config and if found
will use it, which might add wrong paths into cflags/ldflags, since we
depend on llvm-native when building gallium support ( thats when
llvm-config is effective), its better to point llvm-config into native
sysroot so it can add correct paths into compiler/linker cmdline
(From OE-Core rev: 8e6b616066ba0f7f452f929dc7c412e620da9101)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit cc73360b9728812ed6123e30559b77d8e89cc21c)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The comment specifies how to use the variables but uses the older and
now unsupported override syntax. Let's update to match the newer syntax.
Cc: Quentin Schulz <foss+yocto@0leil.net>
(From OE-Core rev: 0a381eea4d50ff1c6e7c7d0d4df62eb581454b48)
(From OE-Core rev: 0e9a70ee3c8f78db746d3cb627c6b212e1b4e4e4)
Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bb64f3fed29b9532e6ddc9a2ba0283d373622d87)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since explicit debug package creation via ${KERNEL_PACKAGE_NAME}-dbg has
been added to kernel, it has to cover all PACKAGE_DEBUG_SPLIT_STYLE
options. For ex. when the variable "debug-file-directory" package search
path has to be set explicitly, otherwise it will not find any files.
(From OE-Core rev: 9adbda8450c57f49edf85e3b3433304e8ac8267e)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 9c39da147683dcaaa244b3ddc4531c4408ad5c9e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Currently, the latest version abseil-cpp contains a new library named "absl_log_internal_format", it's
basic package config(.pc file) as below:
prefix=/usr
exec_prefix=${prefix}
......
Requires: absl_config = 20230125, absl_core_headers = 20230125, absl_log_internal_append_truncated = 20230125,
absl_log_internal_config = 20230125, absl_log_internal_globals = 20230125, absl_log_severity = 20230125,
absl_strings = 20230125, absl_str_format = 20230125, absl_time = 20230125, absl_span = 20230125
......
Normally, the process_pkgconfig() would process variable data before field data in a .pc file, but in the
absl_log_internal_format, the field data in "Requires" section contains "xxxx = xxxx" format, the
process_pkgconfig() treats them as normal variable and using the setVar() in bitbake's data_smart.py
try to process. The absl_log_internal_format field data contains "_append_", this hit the setVar() checking
and finally bitbake stop building and reporting an error as below:
"Variable xxx contains an operation using the old override syntax. Please convert this layer/metadata before attempting to use with a newer bitbake."
This patch move the field data process before variable process to avoid the process_pkgconfig() treat the field
data as variable.
(From OE-Core rev: e7d3e02a624f7ce23d012bb11ad1df2049066b37)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
(cherry picked from commit a73e269d3e591a10bb397b94b82e3fb960112d33)
Signed-off-by: Clément Péron <peron.clem@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
In order to build erofs filesystems, wic must have the erofs-utils package installed into its sysroot.
(From OE-Core rev: c349c7fcb299b123824da9a13ee58222a6cbf9ec)
Signed-off-by: Heiko Thole <heiko.thole@entwicklung.eq-3.de>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Current error message is difficult to read:
ERROR: Nothing PROVIDES 'image'
trs-image was skipped: image - image: normal username test does not have a static ID defined. Add test to one of these files
It's not clear that first "image" is recipe name, second "image" is
binary package name and that "test" is the user account which does not
have a static ID defined. Improve the error message so that these are
more explicit. Now the error message looks like:
image was skipped: Recipe image, package image: normal username "test" does not have a static ID defined.
(From OE-Core rev: 572c507736b2fcc31f7f13cb3da0d5be361838f5)
Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 07898218f3908a83e07178b6530dfa48d55d4ec2)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
I've encountered issues reproducing initramfs and UKI image builds,
which will be fixed with this patch.
1. initramfs
There's a symbolic link to /sbin/init, which is appended to the cpio archive after creation.
The links timestamp needs to be static and the cpio append command needs the '--reproducible' flag to produce deterministic outcomes.
2. Unified Kernel Image
'--preserve-dates' is required for a static 'Time/Date' entry.
I've added '--enable-deterministic-archives' although in my case this
didn't change anything.
(From OE-Core rev: 0d8890f7c1fbea5036acefa3031dcd442b316725)
Signed-off-by: Frieder Paape <frieder@konvera.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit fd027729bafb4e085ba0949e38e724f3a8cad102)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
When running prepare_recipe_sysroot task, the extend_recipe_sysroot
is run twice.
What prepare_recipe_sysroot does is executing extend_recipe_sysroot,
there's no need to add extend_recipe_sysroot to its prefuncs.
(From OE-Core rev: dad053c4b99d4aefebe40459500ad53a2b458fa0)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bf7584a2ac16ee46ff5b41536b06bb46d0cbada7)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
If a specific kernel provider or configuration wants to enable BTF
and pahole analysis, it isn't currently possible due to the explicit
definition to false in the base kernel build arguments.
pahole is now detected by the kernel built itself, so unless
pahole-native is enabled, the result is the same.
If a kernel does require an explicit disable of pahole, it is better
to carry PAHOLE=false in those specific recipes.
(From OE-Core rev: 44b75c7442b05a2fedcc0d73982566c2bef84357)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit b1e4851a36ed47ce6ba880a49264b9a57c78cf4f)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Add new fetcher for the NVD database using the 2.0 API [1].
The implementation changes as little as possible, keeping the current
database format (but using a different database file for the transition
period), with a notable exception of not using the META table.
Minor changes that could be visible:
- the database starts in 1999 instead of 2002
- the complete fetch is longer (30 minutes typically)
[1] https://nvd.nist.gov/developers/vulnerabilities
(From OE-Core rev: b8ae26aabe825c1bc8d84fd7e0ee197695f1dee7)
Signed-off-by: Marta Rybczynska <marta.rybczynska@syslinbit.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit fb62c4c3dbca4e58f7ce6cf29d4b630a06411a97)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Upstream's dtb directory structure has no real standard. They just tend
to idle around the 2/3 directory depth. Recursively search for the
dtb/dtbo files instead of assuming anything.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: 717b9f18a51e9c9fd5a471238aa2ea4de439ef17)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Use the notation suggested by Martin Jansa to avoid a bashism. Also
switch KERNEL_DTBVENDORED to the more common 0/1 notation instead of
true/false.
Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb
directory, 2023-05-02)
(From OE-Core rev: b7d6fc07462e6fca09d0db7f43a62920250ef053)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Fedora/Redhat and Arch are somewhat standardized on their dtb directory
structure. Let's add some flags to configure yocto to mimic that
behavior.
Add the following variables to the kernel class:
- KERNEL_DTBDEST (controls the destination directory for dtbs)
- KERNEL_DTBVENDORED (controls if vendor subdirectories are to
be respected)
Currently KERNEL_DTBDEST is expected to be a subdir of KERNEL_IMAGEDEST
and KERNEL_DTBVENDORED is expected to be "true"/"false". This only
applies to the package directory structure. The deploydir structure is
purposely left untouched for compatibility with existing recipes.
By default this is configured to behave the same as the current recipe
and produce a flat dtb directory at KERNEL_IMAGEDEST.
(From OE-Core rev: 77d6118e20751f68ad7104edec8f14dbb5ba6ec1)
Signed-off-by: Randolph Sapp <rs@ti.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Function 'gen_updatealternativesvardeps' still used old override
syntax when fetching variable flags. Update to use ':' instead to match
recipe meta data. This was found by review and no real issue encountered
but it is a bug that affects variable dependencies and can affect rebuilds
as task hashes might not be accurate.
(From OE-Core rev: d5fd577c066fa2fddbd16c286f2dde2883cc7828)
Signed-off-by: Peter Bergin <peter.bergin@windriver.com>
Signed-off-by: Peter Bergin <peter@berginkonsult.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 5691f554b2cd50f256a8cbb1d96781e9eb6b930e)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This is a partial fix for bugzilla 15059 [https://bugzilla.yoctoproject.org/show_bug.cgi?id=15059]
It has been noted by several people that when an initramfs is bundled:
- a lot of the kernel is rebuilt
- it takes a really long time
When looking at the logs, the second kernel compilation (that performs
the bundle) is not using the parallel make settings, and builds with
-j1.
We are already explicitly passing PARALLEL_MAKE when building kernel
modules, and by extending that explicit use to the main kernel
compilation, we ensure that we always get a parallel build.
Build times chnaged from more than 30 minutes for the bundle, to
3 minutes in local testing.
The question of whether or not too much is rebuilding during the
bundle step is still an open question, but with this tweak, at least
the build time is back in the realm of acceptable.
(From OE-Core rev: a2a889b760785474dbc04e3ec11521f6da90161d)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 88fd394ecf0f2174b792075d409d87046896426b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* otherwise it ends '<unknown>' inside esdk, because of parsing order:
# $METADATA_REVISION [3 operations]
# set /OE/build/test-D/conf/local.conf:43
# "f2da54ef432eac89b0f18eaad68e602b6990b5de"
# immediate /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:9
# "${@oe.buildcfg.detect_revision(d)}"
# set /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:10
# [vardepvalue] "${METADATA_REVISION}"
# pre-expansion value:
# "<unknown>"
METADATA_REVISION="<unknown>"
* This causes base-files.do_install and following tasks to have different
signatures between esdk and the build directory where this esdk was created:
bitbake-diffsigs {test-D,poky/build-uninative-disabled}/tmp/stamps/qemux86_64-poky-linux/base-files/*do_install*sigdata*
NOTE: Starting bitbake server...
basehash changed from 5b6981cf58bfd57d416b0e31611b73a26baae635dd1ac31c08d46f95064c3ffc to dbdce042da4d7813d632b6d1cc87a16f728ad20e55fecbc392830e6acf72babd
Variable METADATA_REVISION value changed from '<unknown>' to 'f2da54ef432eac89b0f18eaad68e602b6990b5de'
and an warning from "python3 /OE/build/test-D/ext-sdk-prepare.py" when eSDK is being prepared for use:
WARNING: The base-files:do_install sig is computed to be 83b9c9a6ef1145baac5a1e0d08814b9156af239c58fc42df95c25a9cd8a7f201,
but the sig is locked to 3dc22233059075978e5503691e98e79e7cc60db94259dfcd886bca2291c0add7 in SIGGEN_LOCKEDSIGS_t-qemux86-64
[RP: Add commit about why we need the override for future reference]
(From OE-Core rev: da6f6340f97e80cb1b21f6083ef5d0a9a856eef5)
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
(cherry picked from commit 675ea7281c17f77bf5dea17cfd4d9da0928382a0)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
