On Sunday, 7 September 2025 18:26:19 EDT, James Le Cuirot wrote:
On Sun, 2025-09-07 at 14:43 -0400, Matt Whitlock wrote:
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -147,6 +147,7 @@
_meson_create_cross_file() {
local system cpu_family cpu
_meson_get_machine_info "${CHOST}"
+ local -n CHOST_default="CHOST_${DEFAULT_ABI}"
local fn=${T}/meson.${CHOST}.${ABI}.ini
@@ -181,7 +182,7 @@ _meson_create_cross_file() {
objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
[properties]
- needs_exe_wrapper = true
+ needs_exe_wrapper = $([[ "${CBUILD:-${CHOST}}" !=
"${CHOST_default}" ]] && echo true || echo false)
sys_root = '${SYSROOT}'
pkg_config_libdir =
'${PKG_CONFIG_LIBDIR:-${EPREFIX}/usr/$(get_libdir)/pkgconfig}'
My only
concern is the precise CHOST can vary in the field, so the profile default
might not match. A better way would be for multilib.eclass to preserve the
original CHOST value in another variable before changing it.
multilib.eclass *does* already stash the original CHOST value in
_abi_saved_CHOST. However, we can't lean on that in meson.eclass, as
meson.eclass still has to work even if it's not being run under a multilib
multi-build.
Is there actually a problem, though? This only comes into play in the case
of a non-cross-compiling, non-default-ABI build. As a reminder, we have
three cases to consider:
* The non-cross-compiling, default-ABI case: Meson runs in native mode, so
we don't have a cross file at all.
* The non-cross-compiling, non-default-ABI case: multilib.eclass will have
set CBUILD *exactly* to the value of CHOST_${DEFAULT_ABI}, so the
conditional in meson.eclass is solid, and we will always have
"needs_exe_wrapper = false" in this case. It doesn't matter what CHOST has
been set to.
* The cross-compiling case: CBUILD will be set to something unlike CHOST or
CHOST_${DEFAULT_ABI}, so we will always have "needs_exe_wrapper = true" in
this case. As Eli pointed out, this isn't strictly true, but it makes us no
worse off than we are at present.
Or are you suggesting that an ebuild may alter the value of CBUILD after
multilib.eclass sets it but before meson.eclass checks it? I would argue
that's a trigger of Undefined Behavior.
