0001-Make-CPU-family-warnings-fatal.patch
refreshed for 1.5.2
Changelog:
============
- nasm: Use different test sources for x86 and x86_64
- mdist: correctly detect dirty hg repos with non-English locale, redux
- backend/ninja: Generate sysroot in rust-project.json
- mdist: detect pathological git repo cases and show a slightly better error
- compilers: Pass mode to determine_args, not its string value
- CI: mark arch as skipping frameworks/libgcrypt
- When configuring fails in Github Actions, print folded logs
- Prevent raw exception during project()
- compilers: avoid -Wunused-value compiler warning in CLikeCompiler.has_type()
- compilers: avoid -Wunused-value compiler warning in CLikeCompiler.has_members()
- mformat: better handling of continuation lines
- mformat: detect invalid config
- tests: handle uncommon architecture format for nm
- mformat: regenerate long lines even if they're already multiline
- Add support for LLVM 19 in Debian.
- mformat: provide nice error message instead of backtrace for invalid value
- mformat: A triple string with a ' in it cannot be simplified
- tests/format: Make the compare script more useful
- linkers: skip -export_dynamic flag before MacOS 10.7
- format: fix indentation of comments
- mformat: correctly handle editorconfig files without the root setting
- cargo: Ignore Cargo.lock if toml implementation is missing
- compilers: do not strip '-isystem' from C build arguments
- Fix compiling ObjC/ObjC++ on Windows/MinGW
- mformat: fix formatting of empty build file
- tests: nasm: make it easier to debug generator() style build
- mdist: correctly detect dirty hg repos with non-English locale
(From OE-Core rev: 292b015bae6fdd11f086dc30f385f45ef2f0eb8d)
Signed-off-by: Wang Mingyu <wangmy@fujitsu.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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: 9338bd66a3c9ab5cb781f2ee588306c5b31a3cb5)
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch disables is_debianlike() so that it always returns False in the
name of deterministic builds. However, the caller default_libdir() then
looks at the host filesystem to decide if /usr/lib64 exists and will
return either lib or lib64, so it still isn't deterministic.
This is only used for the default libdir value and meson.bbclass
always passes an explicit --libdir, so this is moot.
(From OE-Core rev: af4200197948f4900761cb1db11680aeab286f92)
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 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: 7bcda141f2019862b4fb5d8dec7956cd8344b420)
Signed-off-by: Liam Beguin <liambeguin@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using meson-native directly from bitbake this has no effect and
everything works as before; the use case is being able to build
meson-driven projects from the 'direct SDK' environment. Build systems
like cmake/autotools are entirely driven by environment variables,
but meson needs configuration files, and so this replicates how SDKs
set things up.
In particular, with this change the libepoxy build test from the SDK
test suite is able to pass.
(From OE-Core rev: 87d4f6d176f27c22dbb99abc271b9a6eaca314f8)
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>
Rebase 0001-python-module-do-not-manipulate-the-environment-when.patch
(From OE-Core rev: 65411c5d632adeac5eab322ae1a54ec8b6d3e5af)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
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>
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>
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>
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>
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>
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>
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>
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>
-meson/0001-Fix-missing-return-statements-that-are-seen-with-Wer.patch
Removed since this is included in 0.51.2.
(From OE-Core rev: 62ea5c31be4a1a5eaba83f81d09b36553febb647)
Signed-off-by: Zang Ruochen <zangrc.fnst@cn.fujitsu.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
