threads / patch / 64565

patch, 2 partsFew fixes for cross-compiling with Meson

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

## tl;dr

11 messages between Dec 2, 2025 and Dec 11, 2025. Diffs are folded; open one to read it.

replies: 10people: 3as markdown or json

Toon Claes· Dec 2, 2025, 10:48 UTC · lore

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

Toon Claes· Dec 2, 2025, 10:48 UTC · re: Toon Claes · lore

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

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(+)
Show changes to subprojects/.gitignore +1 −0
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
Toon Claes· Dec 2, 2025, 10:48 UTC · re: Toon Claes · lore

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

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(-)
Show changes to meson.build +1 −1
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
Patrick Steinhardt· Dec 2, 2025, 20:27 UTC · re: Toon Claes · lore

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

On Tue, Dec 02, 2025 at 11:48:09AM +0100, Toon Claes wrote:
Show 24 quoted lines
> 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
Toon Claes· Dec 3, 2025, 14:55 UTC · re: Patrick Steinhardt · lore

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

Patrick Steinhardt <ps@pks.im> writes:
Show 9 quoted lines
> 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
Toon Claes· Dec 3, 2025, 14:53 UTC · re: Toon Claes · lore

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

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(-)
Show changes to meson.build +1 −2
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
Patrick Steinhardt· Dec 4, 2025, 06:16 UTC · re: Toon Claes · lore

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

On Wed, Dec 03, 2025 at 03:53:31PM +0100, Toon Claes wrote:
Show 15 quoted lines
> 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
Toon Claes· Dec 8, 2025, 14:41 UTC · re: Carlo Marcelo Arenas Belón · lore

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

Carlo Marcelo Arenas Belón <carenas@gmail.com> writes:
Show 5 quoted lines
> 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
Carlo Arenas· Dec 9, 2025, 00:44 UTC · re: Toon Claes · lore

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

On Mon, Dec 8, 2025 at 6:41 AM Toon Claes <toon@iotcl.com> wrote:
Show 10 quoted lines
>
> 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
Toon Claes· Dec 11, 2025, 11:10 UTC · re: Carlo Arenas · lore

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

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

← back to recent threads