In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and
kernel-fitimage.bbclass is in use to generate signed kernel
fitImage, there is a circular dependency between uboot-sign
and kernel-fitimage bbclasses . The loop looks like this:
kernel-fitimage.bbclass:
- do_populate_sysroot depends on do_assemble_fitimage
- do_assemble_fitimage depends on virtual/bootloader:do_populate_sysroot
- virtual/bootloader:do_populate_sysroot depends on virtual/bootloader:do_install
=> The virtual/bootloader:do_install installs and the
virtual/bootloader:do_populate_sysroot places into
sysroot an U-Boot environment script embedded into
kernel fitImage during do_assemble_fitimage run .
uboot-sign.bbclass:
- DEPENDS on KERNEL_PN, which is really virtual/kernel. More accurately
- do_deploy depends on do_uboot_assemble_fitimage
- do_install depends on do_uboot_assemble_fitimage
- do_uboot_assemble_fitimage depends on virtual/kernel:do_populate_sysroot
=> do_install depends on virtual/kernel:do_populate_sysroot
=> virtual/bootloader:do_install depends on virtual/kernel:do_populate_sysroot
virtual/kernel:do_populate_sysroot depends on virtual/bootloader:do_install
Attempt to resolve the loop. Pull fitimage configuration options into separate
new configuration file image-fitimage.conf so these configuration options can
be shared by both uboot-sign.bbclass and kernel-fitimage.bbclass, and make use
of mkimage -f auto-conf / mkimage -f auto option to insert /signature node key-*
subnode into U-Boot control DT without depending on the layout of kernel fitImage
itself. This is perfectly valid to do, because the U-Boot /signature node key-*
subnodes 'required' property can contain either of two values, 'conf' or 'image'
to authenticate either selected configuration or all of images when booting the
fitImage.
For details of the U-Boot fitImage signing process, see:
https://docs.u-boot.org/en/latest/usage/fit/signature.html
For details of mkimage -f auto-conf and -f auto, see:
https://manpages.debian.org/experimental/u-boot-tools/mkimage.1.en.html#EXAMPLES
Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies")
Reviewed-by: Adrian Freihofer <adrian.freihofer@siemens.com>
(From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently, providers are set on a global config basis. This change allows
for a select set of providers to be configured using BB_RECIPE_VIRTUAL_PROVIDERS
on a per recipe basis. This would allow for the selection of virtual/cross-cc
as gcc or clang for example.
The PROVIDERS are removed from the recipes so that if a version of the
dependency accidentally slips through, the build will fail and the user
can correct the issue.
(From OE-Core rev: 6eeab1a5d7f23917b94c130e417d59afb757b546)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The idea of the base class dependency is to say "yes, I need a C cross compiler"
and this was never meant to be gcc specific. Looking at the codebase, whilst we
code triplets into this, it does overcomplicate things as there are only ever
limited, "target", "sdk" and the class extended versions like mutlilib.
After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc.
This lets us remove the "gcc" specific element as well as removing the over
complicated triplet usage.
At the same time, change the much less widely used "g++" variant to "c++" for
similar reasons and remove the triplet from virtual/XXX-binutils too.
Backwards compatibility mappings could be left but are just going to confuse
things in future so we'll just require users to update.
This simplification, whilst disruptive for any toolchain focused layers, will
make improved toolchain selection in the future much easier.
Since we no longer have overlapping variables, some code for that can just
be removed. The class extension code does need to start remapping some variables
but not the crosssdk target recipe names.
This patch is in two pieces, this one handles the renaming with the functional
changes separate in a second for easier review even if this breaks bisection.
(From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html
Drop the following backported patches which is addressed
with rust v1.81.0 upgrade.
0001-cargo-do-not-write-host-information-into-compilation.patch
2db0bab161
hardcodepaths.patch
28503d69ac
(From OE-Core rev: 611ec9ffbac974f472a828277ba7f3e344e99ca3)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Similar to OPKG, overwrite conf files for APT (deb files).
(From OE-Core rev: b1d29b8b05ea7ebdb04f53afc0003bc04d8e71ec)
Signed-off-by: Benjamin Bara <benjamin.bara@skidata.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH},
but this doesn't follow the pattern of all of the other tune-specific
variables in the machine configuration which is VARIABLE:tune-[name].
Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to
QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} for consistency.
Note that this will mean that BSPs need to update any assignments of
this variable.
(From OE-Core rev: 7f981d074442b901f7e64dbdb9db851ff31c3733)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Every other architecture has the QEMU_EXTRAOPTIONS assignments in the
tune files, so move the PPC ones too.
(From OE-Core rev: ba05251c89d8cc243e861886124573c83197e949)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It was created in 2004 as an alternative to hdparm and never updated since
(while hdparm remains in active development).
(From OE-Core rev: 54c1243a259a2f6407c0202d03414fc5272b2d90)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Being able to set maintainers is really a "per layer" configuraiton item. Use
include_all so that such maintainer information would be added for all configured
layers, if the layer chooses to have such information in a
conf/distro/include/maintainers.inc file in a given layer.
(From OE-Core rev: d6b9dc4629642a4bf0d8f34a90bd8e3291c87501)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
"packaged staging" is obsolete and now we have sstate. Multimachine is just
the norm now, I doubt people remember how things used to be!
Drop the comment as it is misleading and obsolete.
(From OE-Core rev: 808d2a526e3dd6d77c524d8faa0af3e78cf0bed6)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixing native class extension code highlighted this was missing, we do assume
the system has a working libstdc++ compiler/runtime.
(From OE-Core rev: a9ae7001adeecf420d9a95654ce27d7e7b8f82a5)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With some native dependency handling fixes under discussion,
bash-completiion-native makes it into the dependency chain. Add this
to ASSUME_PROVIDED since we don't want to build it rather than trying
to remove all references in the native case (it comes from
glib-2.0-native).
(From OE-Core rev: 401706ed6d51917d76726098a767932970990805)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There was a report that the existing addfragments statement comes in too late,
specifically after the DISTRO/MACHINE includes have already been handled. The goal
for fragments content is to behave exactly like the settings in local.conf would
and so we need to handle the fragments just after that file.
(From OE-Core rev: e820fa96d078478ea3510164373989090e8c9419)
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>
Drop two patches merged upstream.
(From OE-Core rev: 540ba2ce2f6d138b386d0d7545c197fd7f54edc8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Please see the patch to bitbake for syntax and implementation details.
The path prefix to fragments is in its own variable so it doesn't have
to be hardcoded into tools.
(From OE-Core rev: 5bdbabd7b5d244a44c33065b04dd76dad76888a8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The following recipes recently had their maintainership given up, so
list myself as maintainer for them:
- meson
- python3-markdown
- python3-smartypants
- python3-typogrify
(From OE-Core rev: caaa2d4345e9d9e9f1a313c5f4f1ed4e3539fea3)
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was prompted by sstatetests.SStateHashSameSigs2.test_sstate_allarch_samesigs
where adwaita-icon-theme would fail due to new librsvg introducing
cargo-c-native into dependency path.
Rather than look into why is that, I simply converted the recipe
into the standard 'target + BBCLASSEXTEND' approach.
(From OE-Core rev: 80a2673a3081e623f30f25cc773ac9217e717958)
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>
There are no consumers of this recipe in openembedded-core or in meta-openembedded.
The last consumer was dnf:
https://git.openembedded.org/openembedded-core/commit/?id=05220b4907ab654e829d97ab68d48f76330937dd
(From OE-Core rev: 5915e70469fa53600dd8926ddafcb5459df1a32c)
Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For a very long time my focus hasn't been these recipes
in particular; rather I'm trying to ensure oe-core as a whole
doesn't fall too far behind upstream releases. To better reflect
this reality, I wish to be no longer listed for any specific
recipes.
(From OE-Core rev: b420b575fef9111a264a9ecc3b34a341ee604d97)
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>
VIRTUAL-RUNTIME_keymaps is defined in busybox init manager and also in
some package groups. Defining distro features in recipes is wrong.
Also this is not directly related to init manager.
So move all these definitions to default-providers.inc
(From OE-Core rev: 00f667bb5007a372950a137bf9e8b0e62f44f7d6)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently VIRTUAL-RUNTIME_dev_manager is defined by some init managers
with "??=" and in packagegroup-core-boot with "?=".
This means that this variable is different in this package group and in
all other the recipes.
This was discovered when trying to use new feature INIT_MANAGER when
migrating to scarthgap and using systemd distro. After deleting all
VIRTUAL_RUNTIME providers defined in init-manager-systemd udev was
installed additionally via packagegroup-core-boot.
Having a distro settings overriden in single recipe is wrong and needs
to be corrected. Therefore let's define the setting in all init managers
and remove it from packagegroup-core-boot.
core-image-tiny-initramfs has a dilemma - use busybox-mdev even if
distro does not enable it in busybox recipe to keep the image tiny, or
rather not install it even if distro enables it in busybox.
This patch chooses the first option.
(From OE-Core rev: 89e2652ac83f2602d6dd60623a225b88dc67d288)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
python3-rdflib was the last consumer of this recipe in oe-core.
(From OE-Core rev: 72cc499429b0869385223ba21fe03849c6145b89)
Signed-off-by: Guðni Már Gilbert <gudni.m.g@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
libdisplay-info is a EDID and DisplayID library. Goals:
- Provide a set of high-level, easy-to-use, opinionated functions as
well as low-level functions to access detailed information.
- Simplicity and correctness over performance and resource usage.
- Well-tested and fuzzed.
Since commit a16598b038b2 ("backend-drm: make libdisplay-info
mandatory") from Weston, this library is now mandatory in order to
build weston 14.0.1 and newer.
(From OE-Core rev: aa3fe5a5c00085f5455a66c1033f4124e76239ec)
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move hwdata recipe from meta-openembedded to openembedded-core.
libdisplay-info is now a requirement for Weston, since commit
a16598b038b2 ("backend-drm: make libdisplay-info mandatory"). However,
in order to build libdisplay-info, hwdata is required. Since Weston is
built inside openembedded-core, move hwdata in order to be able to
upgrade Weston, so oe-core has no dependency on meta-oe.
hwdata contains various hardware identification and configuration data.
(From OE-Core rev: 3e5d5ba74beace1669ff04a7b0334aaa2693bdb6)
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
liburi-perl was added in 2010 to support lsb testing, never had
any other consumers in core, and since 2019 lsb testing is gone as well:
https://git.yoctoproject.org/poky/commit/?h=master-next&id=bac4bc9aa6a1f2fcf2ce9644925615185cc8e847
(From OE-Core rev: 945e77e789c93ed889ceca75d61ab7cfd39fb1b8)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updating linux-libc-headers to the 6.12 LTS release, we drop
6.10 and make 6.12 the default.
(From OE-Core rev: ac76d281e28cf0cb42dd76869572fa01716198ca)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We've seen cases where a ptest (strace) has a 43GB sparse file in the test
directory. busybox tar doesn't work well with this. The resulting 1.4GB archive
takes hours to extract too.
Ensure tar is added to our full images and use the sparse option to collect
files for debugging. This stops crazy build hangs.
Since tar is GPLv3, we have to exclude it from that test code. We don't boot
any of those images so the debug collection code is safe there, at least for now.
(From OE-Core rev: fefeb919696b6ac76f0997acfb0f612203ef7f1b)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows using it where only a number is needed, such as rpm compression
setting.
(From OE-Core rev: 9c284b4c661566855f15ba3f4508982c2a60b147)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Following bitbake "cooker: Drop support for BB_DANGLINGAPPENDS_WARNONLY",
show warnings for use of the variable.
(From OE-Core rev: ab0f6898a0f3892a9c4536919adaa1d8d847bb7c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update the patch files with rust v1.80.0.
The patch repro-issue-fix-with-cc-crate-hashmap.patch addresses the rust
reprouciblity issue by correcting the way hash values are generated for
different build paths.
https://blog.rust-lang.org/2024/07/25/Rust-1.80.0.html
(From OE-Core rev: d68449da0df795abe3233383a82d0b6b7908d736)
Signed-off-by: Sunil Dora <SunilKumar.Dora@windriver.com>
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have multiple recipes in core that RPROVIDE virtual-x-terminal-emulator,
so we should pick one to be the default for deterministic builds.
Pick rxvt, as it's the lightest. Sato can depend on matchbox-terminal
explicitly and rxvt will not be added.
(From OE-Core rev: 0c362390127fa30f6932558ebcd9cbe1e21e8467)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I'd be happy to remove expect from core as it has been unmaintained for years,
but sadly gcc/binutils test suites are basically written in it (via dejagnu),
and ltp makes use of it as well.
I attempted porting expect to tcl 9, but it's a tcl extension and makes
extensive use of features that have been deprecated in tcl 8 and removed
in tcl 9, and even pokes into tcl internals.
At some point hopefully the GNU toolchain upstreams are going to notice;
for now we'll carry tcl (latest) and tcl8 recipes.
tcl and tcl8 packages can be co-installed, the latter is adjusted
to contain tclsh8.
tcl-dev and tcl8-dev packages can also be co-installed, a few files
in tcl8-dev are renamed to avoid clashes with tcl-dev (tcl.pc -> tcl8.pc,
and similar for tclConfig.sh and tclooConfig.sh).
(From OE-Core rev: 8ec7bfc6644aff011545dfb0f5a415e79d7b0844)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With bitbake commit 'bb: compress: use lz4 instead of lz4c' we require
lz4, not lz4c [1]. Going as far back as Ubuntu 16.04/Fedora 25, they
are packaged together so it should be safe to simply adjust the
requirement from lz4c to lz4.
Note that the two are largely the same, but upstream has considered lz4c
deprecated since at least 2018 [2].
1. https://git.openembedded.org/bitbake/commit/?id=907472034b344e4eb73cfd43059a413469f52e1c
2. https://github.com/lz4/lz4/pull/553
(From OE-Core rev: fe167e082cbde1c6d186ecdda531abef610ac2ac)
Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I was surprised to realise our buildtools doesn't support IPv6 which breaks
usage in our own autobuilder, let alone anywhere else.
Enable ipv6 in our SDKs and enable acl/xattr as well before we have the same
kind of issues with those, these features are now common on most linux systems
and we should be defaulting to including them.
(From OE-Core rev: e86686cbdbaf5368fae0a490d52a043f8ed4fa0f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was added to OpenEmbedded in 2011[1] for the micro distro[2] and
subsequently ported to oe-core[3]. This feature aims to improve runtime
link speed by removing intermediate symlinks, i.e. libstdc++.so.6 is not
a symlink but the actual library.
However, there are several issues here:
- The meta-micro distribution has been unmaintained since 2012[4]
- The original creator of this function has confirmed that it is not in
use anymore because the renaming doesn't affect the -dev packages, so
on-target development or use of SDKs isn't possible.
Whilst the latter is possible to fix, the performance impact of removing
a single symlink resolution is negliable at best and the packaging code
is already very complex.
So, remove this functionality as it is known to be broken, isn't tested,
and removing it reduces complexity.
[1] https://git.openembedded.org/openembedded/commit/?id=cf7114179ead8ddff8f66e84d630811920ac9add
[2] https://git.openembedded.org/openembedded/tree/conf/distro/micro.conf
[3] https://git.openembedded.org/openembedded-core/commit/?id=600dbb7cb384c2290af38b993a9bea3a4dfc4494
[4] https://git.openembedded.org/meta-micro/
(From OE-Core rev: 9bfdf4c9eff16804588942a13ac7484059197f99)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The original commit incorrectly missed off the pn- override prefix, fix it.
(From OE-Core rev: 766ebeec6fa56305606df3dcf901053dd58c1a95)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
pseudo has to wrap all glibc calls including the 32 bit ones so
this warning is a false positive.
(From OE-Core rev: 13f8b50f055be219aed50c62c5f7552c4c2f18f2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cortexa32 is a 32-bit armv8a architecture processor, so set the tune feature
as armv8a instead of aarch64 which is 64-bit armv8a architecture.
It solves the following build error while compiling libgcc-initial
and libssp-nonshared.
-- snip --
aarch64-poky-linux-musl-gcc: error: unrecognized command-line option '-mfpu=neon'
aarch64-poky-linux-musl-gcc: error: unrecognized command-line option '-mfloat-abi=hard'
-- snip --
(From OE-Core rev: 3b898270aca62559dfa42ed71d296fe8a8b46a41)
Signed-off-by: Jagadeesh Krishnanjanappa <workjagadeesh@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop the gnutls patch since something equivalent was merged upsteam.
(From OE-Core rev: 3e1b5805906dc3b2f7c79d26224a7a732123af97)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fabio has been keeping the U-Boot recipe up to date for a long time
in a timely manner, doing a great job there, update the maintainers
file.
(From OE-Core rev: ba8d7c7d066ae4923a7494775077f23939183d21)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kdump script from kexec-tools does not work without makedumpfile (see https://git.yoctoproject.org/poky/tree/meta/recipes-kernel/kexec/kexec-tools/kdump#n14 ).
Thus, let's import makedumpfile from meta-openembedded/meta-oe/recipes-kernel/makedumpfile and make kexec-tools RDEPENDS on makedumpfile.
makedumpfile is the utility which reads /proc/vmcore after a kernel panic and creates a kdump file under /var/crash/.
(From OE-Core rev: 8534e6427622ec76e100b7d10ee11d180cf5980a)
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable was removed in
https://git.yoctoproject.org/poky/commit/?id=2f46b6f27dfa3a9d5ad177900fcecfe64c3536f1
("bitbake.conf: drop VOLATILE_TMP_DIR, use FILESYSTEM_PERMS_TABLES instead")
so ensure that distributions become aware that it no longer has any
effect.
(From OE-Core rev: ec032dd13a19e4d4a332f06ace87f1f02143c3b2)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This variable was removed in
https://git.yoctoproject.org/poky/commit/?id=2f8806deb7655b37d6f8d12ff54680d6acf7a298
("bitbake.conf: drop VOLATILE_LOG_DIR, use FILESYSTEM_PERMS_TABLES instead")
so ensure that distributions become aware that it no longer has any
effect.
(From OE-Core rev: a951a900ce459191a9796a7069a1d3b658dda88f)
Signed-off-by: Niko Mauno <niko.mauno@vaisala.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
While enabling multilib, build gcc-source-14.2.0 and lib32-gcc-source-14.2.0
at the same time:
$ MACHINE = "qemux86-64"
$ require conf/multilib.conf
$ MULTILIBS = "multilib:lib32"
$ DEFAULTTUNE:virtclass-multilib-lib32 = "x86"
$ bitbake gcc-source-14.2.0 lib32-gcc-source-14.2.0
...
$ cat tmp-glibc/work-shared/gcc-14.2.0-r0.vr2401/temp/log.task_order
20241012-064533.415426 do_recipe_qa (2688052): log.do_recipe_qa.2688052
20241012-064533.463783 do_recipe_qa (2688051): log.do_recipe_qa.2688051
20241012-064533.805164 do_fetch (2688257): log.do_fetch.2688257
20241012-064533.852955 do_fetch (2688256): log.do_fetch.2688256
20241012-064617.823714 do_unpack (2698542): log.do_unpack.2698542
20241012-064617.871730 do_unpack (2698541): log.do_unpack.2698541
...
There are two tasks for do_fetch, do_unpack and others, so there are race issues.
Both of them have the same hardcode 'gcc' prefix in ${WORKDIR} and
${S}, explicitly disable lib32-gcc-source-14.2.0 for multilib
Set gcc-source as BPN of gcc-source-14.2.0
(From OE-Core rev: 901c47877e0710af50639f688e0bfdb851b762b5)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These are set in the barebox class rather in the corresponding machines
(where they would belong otherwise) to keep the impact of barebox to
oe-core minimal for now.
"multi_v7_defconfig" is used for qemuarm since this is the default
barebox armv7 config that just enables all supported platforms.
"multi_v8_defconfig" is used for qemuarm64 sine this is the default
barebox armv8 config that just enables all supported platforms.
"efi_defconfig" is used for qemux86-64 which is the primary platform
where barebox will not be the first stage bootloader but an EFI payload.
Since these changes make barebox a provider for virtual/bootloader,
explicitly default to u-boot in the corresponding MACHINE configs to not
unnecessarily surprise users.
(From OE-Core rev: 93da14f8f85202bad3dec9d979d01f4e8f9708d6)
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add initial support to build the barebox tools for the host and the
target.
Some of the tools are generic barebox utilities (like 'bareboximd' for
image meta data inspection or 'bareboxenv' for accessing the barebox
environment) some are SoC family-specific specific utilities (like
'imx-usb-loader' or 'omap3-usb-loader').
(From OE-Core rev: cb3de34a28cde3f9ebd52ba842da9f91c6f0fa66)
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds the support for the barebox bootloader to oe-core. The recipe
is inspired by meta-ptx [1] but is a major rework of the one found there.
Barebox comes with a wide range of supported architectures and follows
the concepts of Linux in various aspects like the driver model, the
shell, or the virtual file system.
This not only eases porting Linux drivers but also makes barebox a
developer-friendly and feature-rich bootloader alternative [2].
For barebox (like for the kernel or other bootloaders) it is quite
likely that people will not just build the original recipe but need to
adapt it, point to custom repositories, apply patch stacks,
COMPATIBLE_MACHINE etc. They may also choose to have different recipe
names for different variants.
Having only a single .bb file and requiring to copy or .bbappend it is
inconvenient and results in unnecessary code duplication. Therefore, the
base support for building barebox is encapsulated in barebox.bbclass
(like kernel.bbclass for the kernel).
Adds barebox to maintainers.inc but excludes it from the maintainers
check since with the current check mechanism barebox would be skipped
(and making the check fail) due to not being the PREFERRED_PROVIDER for
virtual/bootloader.
[1] https://github.com/pengutronix/meta-ptx/tree/master/recipes-bsp/barebox
[2] https://www.barebox.org/demo/?graphic=0
(From OE-Core rev: 5c69f5626278a6e9756188a5771b18075380f52d)
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Enrico Jorns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
GDB 15.2 brings the following fixes:
* PR gdb/31727 (-exec-next fails in mingw (infrun.c:2794: internal-error: resume_1: Assertion `pc_in_thread_step_range (pc, tp)' failed))
* PR c++/31900 (libstdc++-prettyprinters/debug.cc print redirected fails since gdb-14-branchpoint-2123-g4e417d7bb1c)
* PR python/31946 (sys.exit from Python no longer exits the GDB process)
* PR record/31971 (Loading a saved record file asserts if we try to execute the inferior)
* PR gdb/32005 (frv_current_sos doesn't set solib::lm_info)
* PR exp/32015 (GDB crashes while printing large D array)
* PR gdb/32025 (Fatal error when the disassemble command is interrupted with SIGINT)
* PR gdb/32143 ([15 Regression] arch/amd64.c:71: internal-error: amd64_create_target_description: Assertion `!is_x32' failed)
* PR symtab/32158 ([gdb/symtab] enum class enumerator has incorrect parent in cooked index)
* PR symtab/32160 ([gdb/symtab] Parent map: die parent or scope parent?)
(From OE-Core rev: 76567e7a0e1d133b5878a0254a9dcc87b3a15bc1)
Signed-off-by: Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
