Ubuntu 25.10 has changed the default coreutils implementation from GNU
coreutils to uutils/coreutils. Unfortunately this causes build problems:
couldn't allocate absolute path for 'null'.
tail: cannot open 'standard input' for reading: No such file or directory
install: failed to chown '...': Invalid argument (os error 22)
Clear build failures happen in 'install' and 'tail', but there may be
further breakage.
Luckily, Ubuntu also installs GNU coreutils with a binary prefix of
'gnu', so whilst these issues are root-caused and fixed in either pseudo
or uutils we can prefer the gnu-prefixed binaries where they are present.
[ YOCTO #16028 ]
(From OE-Core rev: 16f2684ebeffa72b5d90525cf9102751b68c298e)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
use TOOLCHAIN_NATIVE variable for selecting native compiler
Default it to PREFERRED_TOOLCHAIN_NATIVE, a recipe which wants
to enforce a toolchain can do so with
for cross toolchains ( e.g. target, nativesdk )
TOOLCHAIN = "gcc"
For native
TOOLCHAIN_NATIVE = "gcc"
This helps build native recipe with clang as native compiler.
(From OE-Core rev: 546baa210acacff5dde6ce55e9842b90277bc9a8)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The intent has always been to share DL_DIR, so set the umask accordingly
to the new OE_SHARED_UMASK variable and match expectations.
(From OE-Core rev: 00e9bfbd29f3959adfc2c64ec78285a11ff83821)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Potentially there could be a grace period for fixing recipes (with warnings, etc),
on the other hand, changes to git unpacking destination would already
break various layers, so we might as well make this a hard qa error and drop
the magic at the same time.
I commit to sending fixes for layers included in autobuilder testing
(meta-oe/arm/intel/virt/agl/aws/mingw/etc).
SOURCE_BASEDIR is at the same time adjusted to be calculated relative
to UNPACKDIR (previously it only worked if S was set to
WORKDIR/something/otherthing, and that is no longer working). It is also
no longer removed from the filesystem, as content of unpackdir is managed elsewhere.
(From OE-Core rev: 53e9ea30aaf48292307b4cff6964bead74c69fff)
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>
This change implements a toolchain selection mechanism. Selection is
made using a set of variables, primarily PREFERRED_TOOLCHAIN_TARGET which
defaults to gcc.
It uses the familiar name for toolchain e.g. "gcc" which selects GNU
compiler + binutils as default C/C++ toolchain or "clang" which will
use LLVM/Clang Compiler. Layers an add their own toolchain definitions
too.
There are also PREFERRED_TOOLCHAIN_NATIVE and PREFERRED_TOOLCHAIN_SDK
which will ulitmately allow selection of the toolchain used for the
native/cross and nativesdk/crosssdk compilers. This currently isn't
functional but is essential to the patch to ensure things are set
to the existing gcc support in those cases.
Users would most commonly want to set:
PREFERRED_TOOLCHAIN_TARGET ?= "clang"
in local.conf or other distro specific global configuration metadata.
It is also selectable at recipe scope, since not all packages are
buildable with either clang or gcc, a recipe can explicitly require
a given toolchain using the TOOLCAHIN variable, e.g. glibc can not
be built with clang therefore glibc recipe sets:
TOOLCHAIN = "gcc"
The TOOLCHAIN variable is distinct from the user preference so recipes
with specific requirements can be identified. This also allows different
polcies to be be specified for native/SDK cases in the future.
(From OE-Core rev: 45bdedd213aff8df3214b95ef2a8551c0abd93a0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the new deferred class event to set the class overrides earlier.
This improves interaction of the override with PACKAGECONFIG values
that control conditional inherits (such as python support).
This also allows toolchain configuration in an easier and more user
friendly way.
(From OE-Core rev: d58f94d5684332bd4fac3747688558bb261b9c63)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We don't have many cross recipes that use PACKAGECONFIG but gdb-cross does,
so correctly remap dependencies for that case allowing the gdb recipe to be
simplified.
(From OE-Core rev: c5bb7976f4d6e8559b4b87e4c3f39135dbb40ef8)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meta-oe has switched from p7zip to 7zip.
p7zip recipe does not exist anymore and p7zip is provided and rprovided
by 7zip recipe.
Use real provider instead of replaced one.
(From OE-Core rev: 5aa516bfa295d5be919459dfe45f452cdec45e81)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes are much more readable with whitespace around the assignment operators.
Fix various assignments in OE-Core to show this is definitely the preferred
formatting.
(From OE-Core rev: 30ea609d3357fb3de911f2f6a5e6856c151b976a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
So that value "0" can turn them off.
(From OE-Core rev: 1a2afcd0773c5ec5946d1dfc27bde585c52a5724)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
During handle PACKAGECONFIG, DEPENDS/RDEPENDS/RRECOMMENDS is appended by
calling function appendVar according to the PACKAGECONFIG setting:
PACKAGECONFIG[f1] = "\
--with-f1, \
--without-f1, \
build-deps-for-f1, \
runtime-deps-for-f1, \
runtime-recommends-for-f1, \
packageconfig-conflicts-for-f1"
[snip of base.bbclass]
pkgconfigflags = d.getVarFlags("PACKAGECONFIG") or {}
if pkgconfigflags:
...
appendVar('DEPENDS', extradeps)
appendVar('RDEPENDS:${PN}', extrardeps)
appendVar('RRECOMMENDS:${PN}', extrarrecs)
...
[snip of base.bbclass]
After following commit in meta-oe,
[fe3ba7ac5c cryptsetup: demote udev runtime dependency to recommendation]
'udev lvm2' changed from RDEPENDS to RRECOMMENDS, but RRECOMMENDS is not
handled in this process, and causes following error:
$bitbake lib32-cryptsetup
ERROR: QA Issue: lib32-cryptsetup package lib32-cryptsetup - suspicious values 'udev lvm2' in RRECOMMENDS [multilib]
In layer openembedded-core, we do have very few recipes that have
runtime-recommends-for-f1 in PACKAGECONFIG setting, but f1 is not
enabled in PACKAGECONFIGS, so not report error when multilib is enabled.
(From OE-Core rev: 2f539a1318a80d3ad5d0d43a9ba4070465e402af)
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of checking for incompatible licenses in the anonymous python
and setting '_exclude_incompatible-', (re)check all the packages in
populate_packages(). This ensures that all packages are processed, even
dynamically generated ones.
The use of the '_exclude-incompatible-' variable set in base.bbclass has
been the mechanism used for per-packages licenses since it was added as
a feature (although with different names for the variable throughout
history). However, since this misses dynamic packages, calling
oe.license.skip_incompatible_package_licenses() a second time on the
actual final package set is a better solution.
(From OE-Core rev: 1816c5a5e724a7f907c9afe4a47b6699ea081ace)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves the code that skips packages with incompatible licenses to the
library code so that it can be called in other locations
(From OE-Core rev: 86eb409e3c1b30110869ec5a0027ae2d48bbfe7f)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Moves several of the functions in license.bbclass to be library code
New function dependencies were manually verified using bitbake-dumpsigs
to ensure that bitbake identified the same dependencies even though they
are now in library code (although the new function names mean that the
task hashes still change)
(From OE-Core rev: 0333e04e353991260c5f67a72f80f3ab9dcf526a)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Now S and B can't be set to WORKDIR, add to PSEUDO_IGNORE_PATHS unconditionally
and simplify the code.
(From OE-Core rev: 26cd2d56261827ad8d07e2145e95f82422accac2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Change do_unpack to unpack files to a subdirectory of WORKDIR instead of WORKDIR
itself. There are several good reasons for this but it is mainly about being able
to isolate the output of the unpack task and tell the files apart from other things
which are created in workdir (logs, sysroots, temp dirs and more).
This means that when the do_unpack task reruns, we can clean UNPACKDIR and know
we have a standard point to start builds from.
It also makes code in tools like devtool and recipetool easier.
To reduce the impact to users, if a subdirectory under UNPACKDIR matches
the first subdirectory under WORKDIR of S, that directory is moved into position
inside WORKDIR. This preserves the behaviour of S = "${WORKDIR}/git",
S = "${WORKDIR}/${BPN}" and other commonly used source directory setups.
The directory is moved since sadly many autotools based projects can't cope with
symlinks in their paths.
The patch also updates reproducible and SOURCE_DATE_EPOCH handling to
match the new potential source locations. We can get rid of the horrible
list of hardcoded directories in WORKDIR to ignore from that code.
(From OE-Core rev: b84eec5c4cbf4b39d6712800dd0d2fe5337721cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Having the unpack directory hardcoded to WORKDIR makes it really hard to
make any changes to the unpack process to try and allow for cleanup for example.
As a first step toward unraveling the intertwined location usages, add a
variable, UNPACKDIR which is where the fetcher is asked to unpack fetched
sources. It defaults to the existing value of WORKDIR at this point.
(From OE-Core rev: e022d62ba917790af2121da57646271ef17c03fa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If you try and fetch using mercurial-native, you see certificate errors since
it is configured to find ones in the sysroot, not the system. Add the missing
dependency so that mercurial recipes using the native tool work.
Found trying to make mirroring for old meta-oe stable branches work.
(From OE-Core rev: fc567e35b374f8b08975602609ee71e64357fb3d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
To improve readability and avoid putting one
inside LICENSE_FLAGS_DETAILS.
(From OE-Core rev: 5e027da9265e58df016fc3ebe45e4400f0e5c7a7)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Source control information being present in PV used to be a hard requirement
for bitbake to operate correctly. Now that hashes are a required part of task
stamps, this requirement no longer exists.
This means we can defer the hash pieces to PKGV and simplify PV.
Use new bitbake fetcher API to inject the source revisions directly into the hash
allowing removal of some horrible code from base.bbclass and avoiding any hardcoding
about how SRCREV may or may not be used.
Use that API to object the string to append to PKGV and append that directly.
The user visible effect of this change is that PV will no longer have revision
information in it and this will now be appended to PV through PKGV when the
packages are written. Since PV is used in STAMP and WORKDIR, users will see
small directory naming and stamp naming changes.
This will mean that sstate reuse through hash equivalence where the source
revision changes but the output does not will become possible as the sstate
naming will become less specific and no longer contain the revision.
The SRCPV variable will no longer be needed in PV and is effectively now just
a null operation. Usage can be removed over time.
(From OE-Core rev: a8e7b0f932b9ea69b3a218fca18041676c65aba0)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Don't prefix the output of LICENSE_FLAGS_DETAILS with "For further
details, see" so that recipes can put arbitrary text in their license
details instead of being limited to a specific sentence structure.
(From OE-Core rev: d606ad5c237d0e28f09f0aa783e83846cbca8d21)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Recipes with proprietary licenses often need to use LICENSE_FLAGS so
that the user can opt-in with consent. However, if you don't consent
then the error simply tells you the license identifier but not further
context.
Add a new variable LICENSE_FLAGS_DETAILS, which will be looked in for a
flag with the name of the licence. If found then the contents are
printed as a source of further details.
For example, a recipe with an EULA may set:
LICENSE_FLAGS = "FooBar-EULA"
LICENSE_FLAGS_DETAILS[FooBar-EULA] = "https://example.com/eula"
If Foobar-EULA isn't in LICENSE_FLAGS_ACCEPTED then the error message is
more useful:
Has a restricted license 'FooBar-EULA' which is not listed in your
LICENSE_FLAGS_ACCEPTED. For further details, see
https://example.com/eula.
(From OE-Core rev: cb5cdcaf3310e889e80861ccfaf46c1bce624ac1)
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>
The previous code had 2 issues:
1. make hosttools/ccache always link to host's ccache (/usr/bin/ccache)
even we have one buildtools
2. make hosttools/gcc etc, link to host's gcc event we have one
buildtools when keyword ccache in buildtools's path, eg:
/mnt/ccache/bin/buildtools
This patch is for fix above issues.
Signed-off-by: Changqing Li <changqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since bitbake now supports an official method to inject python modules,
switch to it.
Anyone using OE_EXTRA_IMPORTS will need to adjust their code accordingly,
probably switching to their own module namespace.
Also switch to using BB_GLOBAL_PYMODULES to list the global modules
to import.
(From OE-Core rev: 1f56155e91da2030ee0a5e93037c62e1349ba89f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I can't see how anyone would be using this very old package function definition
since package.bbclass is always inherited in modern OE. All it seems to do
is waste CPU cycles. Drop it and it's associated EXPORT_FUNCTIONS entry.
(From OE-Core rev: 56f7aa4cc0256aff96a1d720bd1931ea9a9bac8a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
