From an SDK, running a meson setup build without an explicit setup
command can result in a native build when a cross build is expected.
The problem is in meson-wrapper where it tries to detect whether a
setup command is being used. The logic looks through all arguments for
a command, and the first argument it finds that doesn't start with a -
is treated as the command. This doesn't work for an implicit setup
command if any option with a space-separated argument exists. In this
case, the argument is incorrectly selected as the command, causing the
setup command options for the cross build to be excluded from the
command line, and thus a native build.
Improve the logic by just looking at the first argument. If it is
a known comand, then record it. Otherwise just assume it is the
implicit setup command.
Note that this fix does not address the possibility of a new meson
command. Two new echo statements are included to help the user in case
of trouble:
```
~/git/weston-imx$ meson --warnlevel 3 --prefix=/usr -Ddoc=false -Dbackend-drm-screencast-vaapi=false -Dcolor-management-lcms=false -Dpipewire=false -Dbackend-x11=false -Dxwayland=true -Dsimple-clients=all -Dbackend-wayland=false -Dbackend-default=drm -Dbackend-rdp=false -Dtest-junit-xml=false -Dlauncher-libseat=false -Dimage-jpeg=false -Dimage-webp=false -Drenderer-g2d=true build
meson-wrapper: Implicit setup command assumed
meson-wrapper: Running meson with setup options: " --cross-file=/opt/fsl-imx-internal-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/meson/aarch64-poky-linux-meson.cross --native-file=/opt/fsl-imx-internal-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/meson/meson.native "
The Meson build system
Version: 0.63.3
```
(From OE-Core rev: 1f30dedee80669475557d9de5f130b7a23eaa7ec)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 9338bd66a3c9ab5cb781f2ee588306c5b31a3cb5)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The meson-wrapper adds setup options to facilitate cross-compilation.
The current options are exclusive to the setup sub-command and might
cause issues with other sub-commands.
Update the wrapper to make options sub-command specific.
(From OE-Core rev: 6f4764ae2ef06c54dbbf77bcbf07af9390a565c9)
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
(cherry picked from commit 7bcda141f2019862b4fb5d8dec7956cd8344b420)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meson would fail to detect compiler type in some rare care where
specific substring '-xt' is detected in compiler --version output and
it so happens that this string can be generated by clang --version if
clang is installed into a directory containing 'xt-' in its name. with
recipe specific sysroots, this is quite likely to happen in OE build
system as we are seeing the issue with newly proposed gnome-text-editor
recipe
https://lists.openembedded.org/g/openembedded-devel/topic/90150031#96301
(From OE-Core rev: ff75909f2a9e970aaf389e0012888c29f02376e3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rename this class to be python-prefixed to match the other new Python
build system classes.
(From OE-Core rev: 25d6bf8079797906bde7c0cf63a0466c981ba5bb)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
PIP_INSTALL_PACKAGE isn't used anymore, so remove all instances of it
from the recipes.
(From OE-Core rev: 15baf24f750ab2c8b0a46d4a3bf2ae9bfa3d0aff)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Upstream provides a pyproject.toml which declares setuptools.build_meta
to be backend for PEP-517 packaging.
Set PIP_INSTALL_PACKAGE as this recipe does not inherit pypi and
therefor no PYPI_PACKAGE is defined
[YOCTO #14638]
(From OE-Core rev: 0d9bc65139a9cabbeabe166e83f2d61f47d7bdd7)
Signed-off-by: Tim Orling <tim.orling@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Backport patches to epiphany/gcr/g-i to address failures with new meson.
(From OE-Core rev: 2ab302edc33681f94b2cd85b564f6feebe154392)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This allows automated version updates when possible, and reduces friction in manual ones.
(From OE-Core rev: 54d4a767ab7beaa64cfc4c221317ea03b0b119ab)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In qemu, they merged the 32 and 64 bit riscv variants into one target for meson
purposes but this isn't officially supported by upstream meson. In normal builds
this would just be a warning but in OE, this is fatal.
Avoid the fatal errors for now and build as qemu intended whilst this is resolved
by the upstreams.
(From OE-Core rev: 7c1356e762d357dad95decf7b1d6147a2efae174)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This replaces the specific gtkdoc wrapper setting
(which was rejected by upstream in https://github.com/mesonbuild/meson/pull/9627)
with a generic, officially supported and documented exe_wrapper,
which is enabled subject to qemu usermode support
(just as is done for g-i and gtk-doc with autotools).
gtk-doc support is adjusted so that this wrapper is passed to
meson's gtk-doc module, which passes it to gtk-doc.
The adjusted patch is re-submitted upstream.
The side effect of this is that meson is now able to run
target binaries in a generic way when it wants to, so this
may affect cross-builds - hopefully in a positive way.
(From OE-Core rev: 17fb047282a413aae5af991ecf5bbb225e19581e)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Meson, as provided by the SDK, would fail to fetch Wraps' sources on bare
systems (i.e. systems, that only provide little more than the SDK).
This change modifies the wrapper script so that it sets an environment
variable (unless it is already set) that is used to determine valid
certificates for secured connections.
It does not affect bitbake's interaction with meson.
The SDK's SSL directory was not searched, so meson would fail when it tried
to fetch sources via https, that were specified in wrap files.
Specifically `urllib` would fail:
```
<urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1129)>
```
Caution: this patch depends on the underlying C library (i.e. openssl)
to consider this environment variable.
(From OE-Core rev: afad2f09ebbfe395f8fafce8218e26056479fe39)
Signed-off-by: Leif Middelschulte <Leif.Middelschulte@klsmartin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without a native environment file, find_program() can't
locate the native program inside SDK.
That stops wayland compositor using wayland scanner.
(From OE-Core rev: c6aed1084006727e3baf70ab9d1f70d9d2d6c01f)
Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
After meson 0.56.0, <lang>_args and <lang>_link_args would be
regarded as meson built-in options.
(From OE-Core rev: 50c8f654e9006a7c902dd76f75082d4f8d668d0c)
Signed-off-by: Hsia-Jun(Randy) Li <randy.li@synaptics.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop 0003-native_bindir.patch: it doesn't seem to actually define
anything where the use_native parameter is set to true.
Also, the issue should be solved without invasive, custom patching
of the code: via meson.cross, custom .pc files for the items in
question or some other configuration mechanism.
(From OE-Core rev: 191d6d1f614a78ef8496e4357d419c68d1e03170)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was a warning before, but with the patch
that turns it into an error, it needs to be properly addressed.
(From OE-Core rev: b6257f3b88e788af3ee748a8a6366aab819dce3f)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rebase patches; dropped chunks (and cross-prop-default.patch)
have been removed upstream.
Move native-only patches to all-patches, as they're a pain to rebase
separately.
(From OE-Core rev: cb2a7dcc86d784cb9903f69570ddc05e23d36529)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building G-I we want to use *native* binaries (as they need to be
executed) but the *cross* libraries, as otherwise when using the correct
pkg-config binary in native lookups Meson will end up linking native and
cross libraries together.
(From OE-Core rev: 958d7f8cebe863705dc6710b671764879ea68575)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The meson determinism issue is the same frozenset issue we encountered with
python itself. Remove the problematic pyc file until upstream work out the
best way to address the issue (as with core python).
(From OE-Core rev: ad00107dc02b3211f5d1a7fe889f538ee2bc064d)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In 0.57.0, the uid and gid arguments passed to os.chown() when using
install_mode were accidentally swapped, causing files to end up with
incorrect owner/group if the owner and group are not the same.
(From OE-Core rev: 8f19fb08b66cd75616345e96fa5718048daae7fe)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace hacky 0001-gnome.py-prefix-g-i-paths-with-PKG_CONFIG_SYSROOT_DI.patch
with entries in meson.cross.
Rest of the patches are refreshed.
(From OE-Core rev: 85b4aea551ac4a0f47f916957dd9707c81813a2b)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Classes native/nativesdk should be inherited last to prevent unexpected
behaviour.
See [YOCTO #5729] for details.
(From OE-Core rev: 217a8974765693192cbead51ebd9845a383ef7cc)
Signed-off-by: Tomasz Dziendzielski <tomasz.dziendzielski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the current version of meson, some path variables only
accept a string not a list.
(From OE-Core rev: 68f20ac5524a5db8a09a90df796b4862cf747d3c)
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
I know the environment setup script would set PKG_CONFIG_PATH,
but the meson won't take that env when translate the includedir
property from the pkg-config.
(From OE-Core rev: 4ac692422526a2924602df410d7562b31d36c0ae)
Signed-off-by: Randy Li <ayaka@soulik.info>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
meson had a bug where they started looking for static boost libraries
first vs. the default behavior of looking at shared libraries first.
This caused issues because some projects assume the shared libraries
first which automatically add in other shared library dependencies.
Static libraries do not have the default behavior so projects that use
boost start failing to compile with undefined references to other boost
libraries.
(From OE-Core rev: 17d1d8de8c4d50d42882586244ae5eef3a111a3c)
Signed-off-by: Andrew Geissler <geissonator@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop 0001-mesonbuild-environment.py-check-environment-for-vari.patch
as upstream has refactored the code.
(From OE-Core rev: 1264edce86cafaa64428bb42844437ac4de7df3a)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Unset LD, and do not set ld in cross file from LD as
new version of meson passes that value directly
to -fuse-ld=... which requires one of lld, bfd, gold.
(From OE-Core rev: e0e30637a139feb744ca284aa63d47efefc5cb5d)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add a backported commit from upstream which helps fix build failures
in meta-oe.
(From OE-Core rev: 6665e84bfba43cd8897b9561b14975ac524fbbe2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Meson 0.51 onwards detects if a build is cross by whether the host and build
machines match. However this doesn't work in a number of cross compilation
cases: notably where host is Windows but build is Linux, but also the common
OpenEmbedded case where the host and build machine are both x86-64.
Previously we'd patched this to instead look at whether an executable wrapper is
needed: our cross files always set this to true so all cross builds would be
identified as cross. However, this breaks build on the target as without a
cross file the early cross build detection fails as we don't yet know if an exe
wrapper is needed.
The neater solution is to simply go back to the older logic: a cross build has
cross files defined.
[ YOCTO #13571 ]
(From OE-Core rev: 9aa543aa9bd78c63343ae28fc85113ca2c9e0094)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
