# [PATCH 0/2] Few fixes for cross-compiling with Meson 11 messages from 2025-12-02 to 2025-12-11. Participants: Toon Claes, Patrick Steinhardt, Carlo Marcelo Arenas Belón, Carlo Arenas. Thread: https://gitlist.dev/t/64565 ## Toon Claes, 2025-12-02 10:48 Subject: [PATCH 0/2] Few fixes for cross-compiling with Meson Message-ID: <20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com> URL: https://gitlist.dev/e/20251202-toon-cross-compile-v1-0-cabc8bce529f%40iotcl.com ``` 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, 2025-12-02 10:48 Subject: [PATCH 1/2] meson: ignore subprojects/.wraplock Message-ID: <20251202-toon-cross-compile-v1-1-cabc8bce529f@iotcl.com> URL: https://gitlist.dev/e/20251202-toon-cross-compile-v1-1-cabc8bce529f%40iotcl.com In-Reply-To: <20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com> ``` 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 --- 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 ``` ## Toon Claes, 2025-12-02 10:48 Subject: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible Message-ID: <20251202-toon-cross-compile-v1-2-cabc8bce529f@iotcl.com> URL: https://gitlist.dev/e/20251202-toon-cross-compile-v1-2-cabc8bce529f%40iotcl.com In-Reply-To: <20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com> ``` 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 --- 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 ``` ## Patrick Steinhardt, 2025-12-02 20:27 Subject: Re: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible Message-ID: URL: https://gitlist.dev/e/aS9LvvjW7mZStceJ%40pks.im In-Reply-To: <20251202-toon-cross-compile-v1-2-cabc8bce529f@iotcl.com> ``` 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 > --- > 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, 2025-12-03 14:53 Subject: [PATCH 3/2] meson: use is_cross_build() where possible Message-ID: <20251203145331.621529-1-toon@iotcl.com> URL: https://gitlist.dev/e/20251203145331.621529-1-toon%40iotcl.com In-Reply-To: <20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com> ``` 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 --- 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 int main(int argc, const char **argv) -- 2.52.0 ``` ## Toon Claes, 2025-12-03 14:55 Subject: Re: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible Message-ID: <87ms3zwr6h.fsf@iotcl.com> URL: https://gitlist.dev/e/87ms3zwr6h.fsf%40iotcl.com In-Reply-To: ``` Patrick Steinhardt 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 ``` ## Patrick Steinhardt, 2025-12-04 06:16 Subject: Re: [PATCH 3/2] meson: use is_cross_build() where possible Message-ID: URL: https://gitlist.dev/e/aTEnIOjhi_XtHdX8%40pks.im In-Reply-To: <20251203145331.621529-1-toon@iotcl.com> ``` 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 ``` ## Carlo Marcelo Arenas Belón, 2025-12-07 10:17 Subject: Re: [PATCH 0/2] Few fixes for cross-compiling with Meson Message-ID: <3tucvydzaelj2mngkocb75l52nssxkkdtt3dj4paviatd3uvnc@u2sy4vig7owz> URL: https://gitlist.dev/e/3tucvydzaelj2mngkocb75l52nssxkkdtt3dj4paviatd3uvnc%40u2sy4vig7owz In-Reply-To: <20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com> ``` 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 ``` ## Toon Claes, 2025-12-08 14:41 Subject: Re: [PATCH 0/2] Few fixes for cross-compiling with Meson Message-ID: <874iq1vxwt.fsf@iotcl.com> URL: https://gitlist.dev/e/874iq1vxwt.fsf%40iotcl.com In-Reply-To: <3tucvydzaelj2mngkocb75l52nssxkkdtt3dj4paviatd3uvnc@u2sy4vig7owz> ``` Carlo Marcelo Arenas Belón 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 ``` ## Carlo Arenas, 2025-12-09 00:44 Subject: Re: [PATCH 0/2] Few fixes for cross-compiling with Meson Message-ID: URL: https://gitlist.dev/e/CAPUEspjifD8MYp6UR4pE91OqcJQdFafpeG8zNo1kfdxhnch_3A%40mail.gmail.com In-Reply-To: <874iq1vxwt.fsf@iotcl.com> ``` On Mon, Dec 8, 2025 at 6:41 AM Toon Claes wrote: > > Carlo Marcelo Arenas Belón 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, 2025-12-11 11:10 Subject: Re: [PATCH 0/2] Few fixes for cross-compiling with Meson Message-ID: <87ikedgtpb.fsf@iotcl.com> URL: https://gitlist.dev/e/87ikedgtpb.fsf%40iotcl.com In-Reply-To: ``` Carlo Arenas 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 ```