Some build systems (notably, Meson) like to be told when cross-compiling
what the target endian and word size is. We don't have these exported
via the variables, so add them using siteinfo as a source of data.
(From OE-Core rev: c2fee816cae6dbedcb40f15be4a1b9ee91757a64)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel has special handling of ${S} and it is therefore expected to be empty
at do_unpack time. For now, ignore this QA check until the kernel unpack process
can be more standardised.
(From OE-Core rev: f2f3f965d6d5fc19b357891e8c55473782124662)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The go class has its own fork of the base unpack code. At the time I was
told this was fine, it now isn't as that code is changing.
Rather than have a fork, put the path magic into a variable and then go
recipes can just set SRC_URI appropriately, e.g.:
git://go.googlesource.com/example;branch=master;protocol=https;destsuffix=${GO_SRCURI_DESTSUFFIX}
This avoids having special case hacks in the class and makes everything
a little more obvious.
(From OE-Core rev: cc4ec43a2b657fb4c58429ab14f1edc2473c1327)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only real reason for oe-local-files was to support S = WORKDIR. With changes to
drop support for that, it makes sense to simplify devtool and to try and make both
the code and the processes/workflows simpler.
This patch drops support for S = WORKDIR, removes oe-local-files and then updates
the test cases to match this new situation.
At the code level, we assume we can always now track code changes using git and
that things committed into git are handled as patches (as before) but delta against
HEAD is saved as specific file level changes to the recipe.
One test is disabled as it is no longer approproate. It is being keped until we can
make WORKDIR != UNPACKDIR at which point it should be revisited.
(From OE-Core rev: ce8190c519052fed10b5233697b69a75868db45a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace references of WORKDIR with UNPACKDIR where it makes sense to do
so in preparation for changing the default value of UNPACKDIR.
(From OE-Core rev: 1f18b9a512800860d5153d89eb82b56388efad6f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The variable uninative_checksum is returned without being set, causing a
build error. Set it to None by default instead.
(From OE-Core rev: 69ead1f2d403e6a0e5365ce4e89288f846d3ef33)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit c991f9d6031 ("image_types: Set SOURCE_DATE_EPOCH for squashfs"),
I assume, the EXTRA_IMAGECMD:squashfs* variable(s) has been ignored.
This is due to the override magic, which isn't applied to functions
called by IMAGE_CMD:<type>, but only to the IMAGE_CMD:<type> itself.
Other image types (e.g. ext*) works around this by passing the
EXTRA_IMAGECMD variable as an argument to the called function.
To do the same for oe_mksquashfs(), the number of mandatory arguments is
fixed to one (with a little logic to handle the zstd filename). This
allows passing ${EXTRA_IMAGECMD} as an argument to oe_mksquashfs(),
which makes the variable functional again.
(From OE-Core rev: e6c1e3a65c3672473dcd01e4a950f89b70121d6b)
Signed-off-by: Martin Hundebøll <martin@geanix.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using multiple u-boot configurations in UBOOT_CONFIG, the helper
function uboot_assemble_fitimage_helper() was not called with all
combinations of type & binary, due to a copy-n-paste indexing error.
(From OE-Core rev: 2d338548a4b745a71eaf6c29231adc93c4165778)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Work through the initial issues I found where we need to change WORKDIR
to UNPACKDIR.
(From OE-Core rev: 86fec41b1e809d1a2fa2feadc26d29020df53d39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
${COREBASE}/scripts contains a "git" wrapper disabling fakeroot/pseudo.
This patch allows CMake to find ${COREBASE}/scripts/git instead of
${HOSTTOOLS_DIR}/git. This is needed for git invocations during do_install,
since do_install is a fakeroot task, and otherwise all git commands fail
with "fatal: detected dubious ownership in repository ...".
I don't know how common it is for CMake projects to invoke git during the
install phase intentionally. It's probably more common to do this during
the configure phase. However, the install step may re-run the configure
step, if some dependencies changed.
In my case, this happened in incremental Yocto builds which reran
do_install and repopulated parts of the recipe-sysroot during that,
without first rerunning do_configure or do_compile. One of the dependencies
changed (but only changing a file in some unrelated sub-package of it which
was not even installed into the recipe-sysroot), causing the dependant's
recipe-sysroot to be repopulated during do_install and thus causing the
CMake project to be reconfigured during do_install.
(From OE-Core rev: c1d1252032a5f146ad91eafc6f57ab4ea2a72e9c)
Signed-off-by: Daniel Klauer <daniel.klauer@gin.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 7ef767d84d56b25498e45db83bb8f9d9caebeaf9)
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>
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
(From OE-Core rev: 943c6acf855fd9de592f0b77828242c2c6e0869f)
Signed-off-by: Michael Glembotzki <Michael.Glembotzki@iris-sensing.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit 827c60b79e7fcafd14e68870f6b69dcc48ac9c39.
Fixed with the drop of the linkmode
(From OE-Core rev: 8f46f60a703defc3e74adad382320c129cef0b06)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This will make possible to restore the default dynamic linking globally
which is what we had before the 1.20.X release.
(From OE-Core rev: 6ad90fc2fc49c4199a59dfb1c1d81a7ba184a522)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable is only used when constructing a SRC_URI and some recipes
think that it's the correct value to assign if the PyPi package name
isn't the same as the recipe name, when PYPI_PACKAGE is actually all
that needs to be set.
Also document the variables we expect the recipe to assign if needed,
and where the PyPi URL structure is documented.
(From OE-Core rev: 0a67d05373ed92bf153bd17e5b32d77ca9f0c353)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ${INITRAMFS_FSTYPES} may contains multi filesystem types,
such as "cpio.gz cpio.xz". So it can't be used directly in setting
of the default INITRD_LIVE. We choose the first filesystem type
in ${INITRAMFS_FSTYPES} for the default INITRD_LIVE.
(From OE-Core rev: aa1a55a90ea86349734e2b62288d54863e01c7b8)
Signed-off-by: Kevin Hao <kexin.hao@windriver.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Overwriting the lsb string without inheriting from uninative causes
shared state cache entries to end up in the wrong path where they are
not beeing picked up by the extensible SDK environment.
(From OE-Core rev: 6a4c83919f27f0f552e9b79aed11e3da6791b7e9)
Signed-off-by: Timon Bergelt <timon.bergelt@pm.me>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When modifying the kernel config by invoking '-c menuconfig' manually, a
sensible next step is to persist this changed configuration somewhere.
A way to do this is to copy the generated .config back to the original
config location.
For this purpose, emit a copy+pasteable printout of the saved .config
path similar to what we have for the fragment location in the
'diffconfig' task already.
Example output:
| Changed configuration saved at:
| /path/to/bsp/build/tmp/work/my-machine-oe-linux/linux-custom/6.6.4/build/.config
| Recompile will be forced
(From OE-Core rev: b104470763b081f040f4fcac564136fc5562f23b)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'FIXME' comment itself says to remove this once the minimum bitbake
version has been bumped. This was in 2012.
The function was introduced in bitbake commit f7b55a94 ("bitbake:
bitbake: ensure -f causes dependent tasks to be re-run") and is already
part of bitbake 1.15.3 which is the minimum bitbake version since
'danny'.
Remove the check.
(From OE-Core rev: 035fe46fbf57ca83baf6610482ee7ee83c825a06)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using meta-clang for llvm kernel compilation previously defaulted to the gcc objcopy tool.
To improve flexibility and compatibility, $OBJCOPY is preferred over $HOST_PREFIXobjcopy
in the kernel-module-split.bbclass.
With $OBJCOPY already defined in bitbake.conf, the empty condition has been removed,
simplifying the invocation process.
(From OE-Core rev: 45366f9162e5a7707c8a46c46b115e8501d367d0)
Signed-off-by: lixiaoyong <lxy204899@163.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Any image that inherits qemuboot must also add image dependencies on
qemu-system-native and qemu-helper-native, otherwise the image won't
be able to be booted.
Currently this is done by conf/machine/include/qemu.inc, but not every
machine that uses qemuboot includes that file.
Move the EXTRA_IMAGEDEPENDS from qemu.inc into qemuboot.bbclass, so that
the dependencies don't have to be duplicated.
(From OE-Core rev: dd54cf058f632e985917ff227483995f368e6a7d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The install task uses a recursive find to check that it can only find
one wheel, but then does a non-recursive glob to install. This can
lead to false-failures if PEP517_WHEEL_PATH points at a directory with
subdirectories.
Solve this mismatch by making the find non-recusive.
(From OE-Core rev: 0142da4768b7818b94601a89bf867e10a0ba0ec0)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The check_oldest_kernel() function requires utsrelease.h to be
generated. This file is generated during do_compile, so we need to delay
calling check_oldest_kernel() until after this.
With this change in place, I now see the expected warning when building
Linux 5.10.y.
(From OE-Core rev: 525019b30e83ea65021ca4874605589ccd2daf80)
Signed-off-by: Paul Barker <paul.barker.ct@bp.renesas.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this commit the configuration node includes the compatible
line 'compatible = [00];' if EXTERNAL_KERNEL_DEVICETREE is not
defined, i.e. if PREFERRED_PROVIDER_virtual/dtb is not used.
This prevents u-boot from using this configuration and it prints the
message "Could not find configuration node".
An additional check also ensures that the written compatible line
never contains an empty compatible.
The functionality to add the compatible line was added in commit
f4c82fb6da89 ("kernel-fitImage: add machine compatible to config
section").
(From OE-Core rev: f8f3a52b2f924789552e6a3f889162ff07e0887f)
Signed-off-by: Christian Taedcke <christian.taedcke@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The GOPROXY is already correctly defined on the native sys root
and this can be checked using the bitbake devshell:
| $ go env GOPROXY
| https://proxy.golang.org,direct
The go_do_compile task calls the compiler directly so the
GOPROXY env is not seen because it's not defined in the shell.
Defining it explicitly solves this problem and was to avoid
setting it in the recipes itself.
(From OE-Core rev: e0919a3f7bc26b1ea9fb57740de4a9a3b9253f26)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Allow tools to be found from the host PATH so that imagemagick from a buildtools
tarball/sdk can work
* Reformat the code to have imports at the start of the file and have more standard
formatting and whitespace
* Always save copies of the images, the space imapct is negligle compared to the
debug win
* Write the images to ${T}
* Use bb.utils.mkdirhier() instead of more complex code
* Restrict the tests to images containing matchbox-desktop
(From OE-Core rev: d09989b49517830297654e4d1d150aaa8723c41a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Remove the appended ${IMAGE_NAME_SUFFIX}, since it is already included
in ${IMAGE_NAME}.
In commit 26d97acc7137 ("image-artifact-names: include
${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
${IMAGE_LINK_NAME}") ${IMAGE_NAME_SUFFIX} was included into
${IMAGE_NAME}. In this commit all other filesystems in
image_types.bbclass were adapted.
(From OE-Core rev: e3460853cdeae78762b31c6a846210f134bcd9ef)
Signed-off-by: Christian Taedcke <christian.taedcke@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The bmaptool (previously: bmap-tools, bmap-tool, bmaptool) has been moved
to be under the Yocto Project umbrella and is now hosted at:
github.com/yoctoproject/bmaptool
[RP: Added a couple of missing renames]
(From OE-Core rev: 7a036b1a1ec7dcd27dbe18d4c2e703bd2a8af182)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With go-1.21 dynamic linking cause a runtime panic:
| root@qemux86-64:~# go-helloworld
| panic: runtime error: index out of range [0] with length 0
|
| goroutine 1 [running]:
| flag.init()
| /usr/lib/go/src/flag/flag.go:1199 +0xf9
In my opinion, this would be a good trade-off so that we can update and
leave the version 1.20 for the next LTS 5.0 since we are already quite
behind on the version available upstream which already has the 1.22 available.
(From OE-Core rev: 827c60b79e7fcafd14e68870f6b69dcc48ac9c39)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 0b0c4b37d318b86f100512476ffd861e0ce1f47e)
Signed-off-by: Fabio Estevam <festevam@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
waf uses an inline tar file extracted by the tarfile module. The tarfile
module may print a warning when used with default 'filter' argument[0].
When called to get the version, the first time after unpack, the output
may look like:
# output from lower modules (e.g: warnings from tarfile, ...)
waf X.Y.Z ...
This patch makes the version parsing more precise by looking at the
first line matching "waf ".
[0]: https://docs.python.org/3.12/library/tarfile.html#extraction-filters
(From OE-Core rev: 643b799a0c11d82907dd82991c19b003fe20a8b0)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some locales are not listed in glibc locales support list, but can be generated,
here using ja_JP.SHIFT_JIS as an example. We can add following line into local.conf
to enable and generate it:
GLIBC_GENERATE_LOCALES += "en_GB.UTF-8 en_US.UTF-8 ja_JP.UTF-8 ja_JP.SHIFT_JIS"
IMAGE_LINGUAS += "ja-jp en-us ja-jp.shift-jis"
The localedef tool would report a warning and exit with 1, that cause build failure,
error message as below:
[warning] character map `SHIFT_JIS' is not ASCII compatible, locale not ISO C compliant [--no-warnings=ascii]
So add a --no-warnings=ascii in libc-package.bbclass to fix build failure if someone needs those locale
in yocto.
(From OE-Core rev: 1048992c0d2a2bda3464185efdac5cc986a583d4)
Signed-off-by: Xiangyu Chen <xiangyu.chen@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
testimage is able to detect whenever a test run leads to some tests
failing, and execute some actions in this case. The only action currently
defined in such case is to retrieve artifacts from the target under test,
as listed in TESTIMAGE_FAILED_QA_ARTIFACTS
In order to be able to add multiple actions, define a central function to
gather all "post actions" to run whenever a test has failed
(run_failed_tests_post_actions). This function contains a table listing all
functions to be called whenever a test fails. Any function in this table
will be provided with bitbake internal data dictionary ("d") and the
current runtime testing context ("tc"). Isolate all this feature in a
dedicated postactions.py file inherited by testimage.
This patch does not bring any functional change.
(From OE-Core rev: c01aa8df0613a103859b4431d3cc5056b2fef1b8)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Multiple places in oeqa need to get the log output path, and redefine a
small helper to accomplish this
Define this helper in lib/oeqa/utils/__init__.py and import it wherever
needed to allow using it.
(From OE-Core rev: 01b1a6a5a4e7cede4d23a981b5144ae9c8306274)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: cd2072e5d953af981339427028e19083257e6a92)
Signed-off-by: Munehisa Kamata <kamatam@amazon.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently there is only one defined imager as part of oe-core's wic
implementation: 'direct'. However, having a highly plugin-based design,
wic allows users to define their own imagers (and sources).
Therefore don't hard-code the filename extension of the imager output to
be 'direct' (i.e. the default imager). Allow the extension to follow the
name of the imager being used.
A user can specify a custom imager via the WIC_CREATE_EXTRA_ARGS variable.
If the user does not specify an imager, then 'direct' is assumed.
(From OE-Core rev: dc5a7c76761ed47e0456228956de900d806063bb)
Signed-off-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit fc8e5d7c13.
We need to use the absolute path to the compiler so that the VSCode
configuration generated by devtool ide-sdk could lint meson projects.
A feature was just added to vscode-cpptools to support conveying the
compilerPath in addition to the compile_commands.json. The next
commits adds the necessary configuration. We can revert this one and
keep the meson paths as they were.
(From OE-Core rev: 9c2faa835bd7af3e6f6bd7cc08495bd4b3ca9d0b)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow interface renaming if 'pni-names' is a distro
feature.
We do not add QB_NO_PNI to QB_CMDLINE_IP_SLIRP because
renaming was never suppressed for slirp.
(From OE-Core rev: d8d92ad46273a4e305f690f2820a475e4d7f6701)
Signed-off-by: Joe Slater <joe.slater@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Despite managing to retrieve the failed ptests artifacts, testimage seems
to dump some retrieval errors like the following one:
WARNING: core-image-ptest-valgrind-1.0-r0 do_testimage: Can not retrieve
/usr/lib/valgrind/ptest from test target
Log the corresponding exception to help analyzing such issue
(From OE-Core rev: 12873e5b1620414a76e4a0e87cc2c806a0513cfe)
Signed-off-by: Alexis Lothoré <alexis.lothore@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #15120]
Consider OVERLAYFS_WRITABLE_PATHS as dependecy of do_create_overlayfs_units() in
order to rebuild the recipe when changing the used mount point.
Tested in a local recipe by changing the used mount point and verified that the
recipe was re-build: passed
(From OE-Core rev: 65423847ac843682d4670d41a94d509f18ce8735)
Signed-off-by: Christoph Vogtländer <christoph.vogtlaender@loewensteinmedical.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Among the files generated by meson is compile_commands.json. It is not
used by bitbake during the build. However, if the devtool workspace is
opened inside an IDE, that IDE can use compile_commands.json to
configure linting and code completion. This is notably relied on by the
new devtool ide-sdk command.
The problem is that the IDE using compile_commands.json does not know
the $PATH set-up by bitbake, so it won't find the compiler. This results
in linting errors, like missing headers. We can fix this by expliciting
the absolute compiler paths in meson.cross.
The compile_commands.json specification expressly states:
"All paths specified in the command or file fields must be either
absolute or relative to this directory."
Link: https://clang.llvm.org/docs/JSONCompilationDatabase.html
An alternative way to implement this is to directly change CXX inside
bitbake.conf to make all recipes use absolute compiler paths.Since this
would affect all recipes, so I would like to have the maintainers'
opinion on this. It could make sense to use absolute compiler paths for
all toolchain binaries, we already do so for the sysroot
TOOLCHAIN_OPTIONS.
Discussions have been opened with meson/ninja maintainers to implement
this at their level:
- https://github.com/ninja-build/ninja/issues/2383
- https://github.com/mesonbuild/meson/issues/12834
These tools have even less information on the environment so it makes
sense for Yocto to provide the absolute paths.
(From OE-Core rev: b4e00248049c2627b05eafa9313a48cf253623fa)
Signed-off-by: Enguerrand de Ribaucourt <enguerrand.de-ribaucourt@savoirfairelinux.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move the PEP-517 back-end bbclass from meta-python to support:
[build-system]
build-backend = "mesonpy"
This is the declared backend in python3-numpy since:
942fb8caf3
(From OE-Core rev: f0d3478913b092a01eceafe0c20378cf9117f429)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python 2 is gone and we don't need the abstraction now, drop the remaining usage
of this variable.
The definition in python3-dir.bbclass is left for now for other layers.
(From OE-Core rev: b566b1e32c7993d1ab7795562f648e52ce186a70)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The 'preinit' script can't create mount directories when rootfs is
read-only. Add an option to skip this step. The user must make sure that
all required directories are already in the rootfs directory layout.
Cc: Vyacheslav Yurkov <uvv.mail@gmail.com>
(From OE-Core rev: 3d433d8559467d255bd19af2d0999c65ea24a48d)
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When cross compiling we have a sysroot, so by telling Meson where it is
explicitly it can do the right thing.
Currently this means it just sets PKG_CONFIG_SYSROOT_DIR to the value
that we already set it to, but in the future this can be used to stop
Meson looking directly in /usr when it shouldn't.
(From OE-Core rev: 62d4fd215a0886056d64e926f722cd07e9986118)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
On AB runs of reproducible-meta-oe/Repro meta-oe/meta-oe,
"waf --version" does not seem to contain the version but an error
message with "RuntimeWarning: <something>" [0].
Since the actual output is not saved anywhere, it is quite hard to
debug.
This patch detects the problematic case and send it to the log where it
will be seen and fixed. As a side-effect, this error will now only be a
warning.
Here is a partial backtrace for this (full back trace visible in [0]):
NOTE: recipe mpv-0.35.1-r0: task do_configure: Started
ERROR: mpv-0.35.1-r0 do_configure: Error executing a python function in exec_func_python() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_func_python() autogenerated', lineno: 2, function: <module>
*** 0002:waf_preconfigure(d)
File: '$TOP/meta/classes-recipe/waf.bbclass', lineno: 58, function: waf_preconfigure
0056: result = subprocess.check_output([python, wafbin, '--version'], cwd=subsrcdir, stderr=subprocess.STDOUT)
0057: version = result.decode('utf-8').split()[1]
*** 0058: if bb.utils.vercmp_string_op(version, "1.8.7", ">="):
[...]
File: '$TOP/bitbake/lib/bb/utils.py', lineno: 91, function: split_version
*** 0091: e = int(s.split(":")[0])
Exception: ValueError: invalid literal for int() with base 10: 'RuntimeWarning'
[0]: https://autobuilder.yoctoproject.org/typhoon/#/builders/155/builds/11/steps/32/logs/stdio line 31883
(From OE-Core rev: 4a82c7ca74075b4c22be94891eecc24238bd0e65)
Signed-off-by: Yoann Congal <yoann.congal@smile.fr>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We had to export TMPDIR because Meson was writing temporary files into
/tmp and then trying to run them, but some systems had /tmp mounted
noexec.
This is now solved upstream as of meson commit 1e182b5 (which was part of
Meson 0.52.0), and these temporary files are written to the build tree
instead.
(From OE-Core rev: 1809d20f92dc0e4eff19cf081ca78a9f30deb611)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This does not seem to have any purpose anymore since the pkg_postinst
from kernel.bbclass always creates relative symlinks from zImage to
zImage-${KERNEL_VERSION}.
(From OE-Core rev: 24ce7e5445962b9b3143036ecb3d44945082ce44)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
