[PATCH 0/2] Few fixes for cross-compiling with Meson

[PATCH 0/2] Few fixes for cross-compiling with Meson

[Toon Claes]

I was cross-compiling for s390x. And while working with Meson is very
convenient, I've found these few kinks that could be worked out.

---
Toon Claes (2):
      meson: ignore subprojects/.wraplock
      meson: only detect ICONV_OMITS_BOM if possible

 meson.build            | 2 +-
 subprojects/.gitignore | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)



---
base-commit: f0ef5b6d9bcc258e4cbef93839d1b7465d5212b9
change-id: 20251202-toon-cross-compile-6c44bb9c372b

[PATCH 1/2] meson: ignore subprojects/.wraplock

[Toon Claes]

When asking Meson to wrap subprojects, it generates a .wraplock file in
the subprojects/ directory. Ignore this file.

See also https://github.com/mesonbuild/meson/issues/14948.

Signed-off-by: Toon Claes <toon@iotcl.com>
---
 subprojects/.gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/subprojects/.gitignore b/subprojects/.gitignore
index 63ea916ef5..2bb68c8794 100644
--- a/subprojects/.gitignore
+++ b/subprojects/.gitignore
@@ -1 +1,2 @@
 /*/
+.wraplock

-- 
2.52.0

[PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible

[Toon Claes]

In our Meson setup it automatically detects whether ICONV_OMITS_BOM
should be defined. To check this, a piece of code is compiled and ran.

When cross-compiling, it's not possible to run this piece of code. Guard
this test with a can_run_host_binaries() check to ensure it can run.

Signed-off-by: Toon Claes <toon@iotcl.com>
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index f1b3615659..95348e69a4 100644
--- a/meson.build
+++ b/meson.build
@@ -1064,7 +1064,7 @@ if iconv.found()
     }
   '''
 
-  if compiler.run(iconv_omits_bom_source,
+  if meson.can_run_host_binaries() and compiler.run(iconv_omits_bom_source,
     dependencies: iconv,
     name: 'iconv omits BOM',
   ).returncode() != 0

-- 
2.52.0

Re: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible

[Patrick Steinhardt]

On Tue, Dec 02, 2025 at 11:48:09AM +0100, Toon Claes wrote:
> In our Meson setup it automatically detects whether ICONV_OMITS_BOM
> should be defined. To check this, a piece of code is compiled and ran.
> 
> When cross-compiling, it's not possible to run this piece of code. Guard
> this test with a can_run_host_binaries() check to ensure it can run.
> 
> Signed-off-by: Toon Claes <toon@iotcl.com>
> ---
>  meson.build | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meson.build b/meson.build
> index f1b3615659..95348e69a4 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -1064,7 +1064,7 @@ if iconv.found()
>      }
>    '''
>  
> -  if compiler.run(iconv_omits_bom_source,
> +  if meson.can_run_host_binaries() and compiler.run(iconv_omits_bom_source,
>      dependencies: iconv,
>      name: 'iconv omits BOM',
>    ).returncode() != 0

We have `not meson.is_cross_build()` in a different location to guard a
call to `compiler.run()`. But `can_run_host_binaries()` is the better
way to test for this condition, as it allows the host to plug in a
wrapper (e.g. QEMU or WINE) that _would_ allow it to execute binaries of
the target host.

`can_run_host_binaries()` is available since Meson 0.55, and we target
a version >=0.61.0. So should we maybe convert that other callsite to
use `can_run_host_binaries()` in a separate commit?

Thanks for these fixes!

Patrick

[PATCH 3/2] meson: use is_cross_build() where possible

[Toon Claes]

In previous commit the first use of meson.can_run_host_binaries() was
introduced. This is a guard around compiler.run() to ensure it's
actually possible to execute the provided.

In other places we've been having the same issue, but here `not
meson.is_cross_build()` is used as guard. This does the trick, but it
also prevents the code from running even when an exe_wrapper is
configured.

Switch to using meson.can_run_host_binaries() here as well.

There is another place left that still uses `not
meson.is_cross_build()`, but here it's a guard around fs.exists(). That
function will always run on the build machine, so checking for
cross-compilation is still in place here.

Signed-off-by: Toon Claes <toon@iotcl.com>
---
 meson.build | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meson.build b/meson.build
index 95348e69a4..00ad8a5c60 100644
--- a/meson.build
+++ b/meson.build
@@ -1492,7 +1492,7 @@ if not has_bsd_sysctl
   endif
 endif

-if not meson.is_cross_build() and compiler.run('''
+if meson.can_run_host_binaries() and compiler.run('''
   #include <stdio.h>

   int main(int argc, const char **argv)
--
2.52.0

Re: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible

[Toon Claes]

Patrick Steinhardt <ps@pks.im> writes:

> We have `not meson.is_cross_build()` in a different location to guard a
> call to `compiler.run()`. But `can_run_host_binaries()` is the better
> way to test for this condition, as it allows the host to plug in a
> wrapper (e.g. QEMU or WINE) that _would_ allow it to execute binaries of
> the target host.
>
> `can_run_host_binaries()` is available since Meson 0.55, and we target
> a version >=0.61.0. So should we maybe convert that other callsite to
> use `can_run_host_binaries()` in a separate commit?

I've sent "PATH 3/2" on top of this series. I've found two occurrences
of `not meson.is_cross_compile()` but only replaced one, because the
other is used to guard `fs.exists()` which (as far as I can tell) always
runs on the build machine.

-- 
Cheers,
Toon

Re: [PATCH 3/2] meson: use is_cross_build() where possible

[Patrick Steinhardt]

On Wed, Dec 03, 2025 at 03:53:31PM +0100, Toon Claes wrote:
> In previous commit the first use of meson.can_run_host_binaries() was
> introduced. This is a guard around compiler.run() to ensure it's
> actually possible to execute the provided.
> 
> In other places we've been having the same issue, but here `not
> meson.is_cross_build()` is used as guard. This does the trick, but it
> also prevents the code from running even when an exe_wrapper is
> configured.
> 
> Switch to using meson.can_run_host_binaries() here as well.
> 
> There is another place left that still uses `not
> meson.is_cross_build()`, but here it's a guard around fs.exists(). That
> function will always run on the build machine, so checking for
> cross-compilation is still in place here.

Thanks! This series looks good to me, including this patch.

Patrick

Re: [PATCH 0/2] Few fixes for cross-compiling with Meson

[Carlo Marcelo Arenas Belón]

On Tue, Dec 02, 2025 at 11:48:07AM -0800, Toon Claes wrote:
> I was cross-compiling for s390x.

Just to clarify, you mean Linux on IBM Z/LinuxOne, not 64bit ZOS/ZVM, right?

Carlo

Re: [PATCH 0/2] Few fixes for cross-compiling with Meson

[Toon Claes]

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:

> On Tue, Dec 02, 2025 at 11:48:07AM -0800, Toon Claes wrote:
>> I was cross-compiling for s390x.
>
> Just to clarify, you mean Linux on IBM Z/LinuxOne, not 64bit ZOS/ZVM,
> right?

I'm sorry, I'm not aware of the correct terminology here.

If I run file(1) on the compiled binary, I'm getting:

    ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV),
    dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0

And readelf(1) says:

    ...
    OS/ABI:                            UNIX - System V
    ...
    Machine:                           IBM S/390
    ...

And the toolchain used was installed from:

    https://aur.archlinux.org/packages/s390x-z13-glibc-bleeding-edge-toolchain

I hope that clarifies it?

-- 
Cheers,
Toon

Re: [PATCH 0/2] Few fixes for cross-compiling with Meson

[Carlo Arenas]

On Mon, Dec 8, 2025 at 6:41 AM Toon Claes <toon@iotcl.com> wrote:
>
> Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
>
> > On Tue, Dec 02, 2025 at 11:48:07AM -0800, Toon Claes wrote:
> >> I was cross-compiling for s390x.
> >
> > Just to clarify, you mean Linux on IBM Z/LinuxOne, not 64bit ZOS/ZVM,
> > right?
>
> I'm sorry, I'm not aware of the correct terminology here.

IBM marketing doesn't make it easier, but yes IBM mainframes can run
multiple OS, and I have to admit I was kind of surprised to read we
had a working meson cross compilation for Z/OS, because I know that at
least cmake has issues even building natively.

> If I run file(1) on the compiled binary, I'm getting:
>
>     ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV),
>     dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0

So this is 64-bit Big Endian linux for the s390x architecture (likely
compatible with z13 or higher CPUs)

I happen to have one of those under the desk running RHEL9/s390x, so
will be happy to test your crosscompiled binaries, assuming it is as
simple as installing them somewhere and running something like `make
test`

Carlo

Re: [PATCH 0/2] Few fixes for cross-compiling with Meson

[Toon Claes]

Carlo Arenas <carenas@gmail.com> writes:

> I happen to have one of those under the desk running RHEL9/s390x, so
> will be happy to test your crosscompiled binaries, assuming it is as
> simple as installing them somewhere and running something like `make
> test`

Thanks for the offer, but I don't think it's needed at the moment.

-- 
Cheers,
Toon