{"thread":{"id":"64565","subject":"[PATCH 0/2] Few fixes for cross-compiling with Meson","startedAt":"2025-12-02T10:48:24Z","lastAt":"2025-12-11T11:10:43Z","messageCount":11,"participants":["Toon Claes","Patrick Steinhardt","Carlo Marcelo Arenas Belón","Carlo Arenas"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"531547","messageId":"20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com","threadId":"64565","inReplyTo":null,"subject":"[PATCH 0/2] Few fixes for cross-compiling with Meson","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-02T10:48:07Z","receivedAt":"2025-12-02T10:48:24Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"I was cross-compiling for s390x. And while working with Meson is very\nconvenient, I've found these few kinks that could be worked out.\n\n---\nToon Claes (2):\n meson: ignore subprojects/.wraplock\n meson: only detect ICONV_OMITS_BOM if possible\n\n meson.build | 2 +-\n subprojects/.gitignore | 1 +\n 2 files changed, 2 insertions(+), 1 deletion(-)\n\n\n\n---\nbase-commit: f0ef5b6d9bcc258e4cbef93839d1b7465d5212b9\nchange-id: 20251202-toon-cross-compile-6c44bb9c372b\n\n"},{"id":"531548","messageId":"20251202-toon-cross-compile-v1-1-cabc8bce529f@iotcl.com","threadId":"64565","inReplyTo":"20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com","subject":"[PATCH 1/2] meson: ignore subprojects/.wraplock","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-02T10:48:08Z","receivedAt":"2025-12-02T10:48:28Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"When asking Meson to wrap subprojects, it generates a .wraplock file in\nthe subprojects/ directory. Ignore this file.\n\nSee also https://github.com/mesonbuild/meson/issues/14948.\n\nSigned-off-by: Toon Claes \n---\n subprojects/.gitignore | 1 +\n 1 file changed, 1 insertion(+)\n\ndiff --git a/subprojects/.gitignore b/subprojects/.gitignore\nindex 63ea916ef5..2bb68c8794 100644\n--- a/subprojects/.gitignore\n+++ b/subprojects/.gitignore\n@@ -1 +1,2 @@\n /*/\n+.wraplock\n\n-- \n2.52.0\n\n"},{"id":"531549","messageId":"20251202-toon-cross-compile-v1-2-cabc8bce529f@iotcl.com","threadId":"64565","inReplyTo":"20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com","subject":"[PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-02T10:48:09Z","receivedAt":"2025-12-02T10:48:32Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"In our Meson setup it automatically detects whether ICONV_OMITS_BOM\nshould be defined. To check this, a piece of code is compiled and ran.\n\nWhen cross-compiling, it's not possible to run this piece of code. Guard\nthis test with a can_run_host_binaries() check to ensure it can run.\n\nSigned-off-by: Toon Claes \n---\n meson.build | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/meson.build b/meson.build\nindex f1b3615659..95348e69a4 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -1064,7 +1064,7 @@ if iconv.found()\n }\n '''\n \n- if compiler.run(iconv_omits_bom_source,\n+ if meson.can_run_host_binaries() and compiler.run(iconv_omits_bom_source,\n dependencies: iconv,\n name: 'iconv omits BOM',\n ).returncode() != 0\n\n-- \n2.52.0\n\n"},{"id":"531585","messageId":"aS9LvvjW7mZStceJ@pks.im","threadId":"64565","inReplyTo":"20251202-toon-cross-compile-v1-2-cabc8bce529f@iotcl.com","subject":"Re: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-12-02T20:27:42Z","receivedAt":"2025-12-02T20:27:51Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Tue, Dec 02, 2025 at 11:48:09AM +0100, Toon Claes wrote:\n> In our Meson setup it automatically detects whether ICONV_OMITS_BOM\n> should be defined. To check this, a piece of code is compiled and ran.\n> \n> When cross-compiling, it's not possible to run this piece of code. Guard\n> this test with a can_run_host_binaries() check to ensure it can run.\n> \n> Signed-off-by: Toon Claes \n> ---\n> meson.build | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/meson.build b/meson.build\n> index f1b3615659..95348e69a4 100644\n> --- a/meson.build\n> +++ b/meson.build\n> @@ -1064,7 +1064,7 @@ if iconv.found()\n> }\n> '''\n> \n> - if compiler.run(iconv_omits_bom_source,\n> + if meson.can_run_host_binaries() and compiler.run(iconv_omits_bom_source,\n> dependencies: iconv,\n> name: 'iconv omits BOM',\n> ).returncode() != 0\n\nWe have `not meson.is_cross_build()` in a different location to guard a\ncall to `compiler.run()`. But `can_run_host_binaries()` is the better\nway to test for this condition, as it allows the host to plug in a\nwrapper (e.g. QEMU or WINE) that _would_ allow it to execute binaries of\nthe target host.\n\n`can_run_host_binaries()` is available since Meson 0.55, and we target\na version >=0.61.0. So should we maybe convert that other callsite to\nuse `can_run_host_binaries()` in a separate commit?\n\nThanks for these fixes!\n\nPatrick\n"},{"id":"531623","messageId":"20251203145331.621529-1-toon@iotcl.com","threadId":"64565","inReplyTo":"20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com","subject":"[PATCH 3/2] meson: use is_cross_build() where possible","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-03T14:53:31Z","receivedAt":"2025-12-03T14:54:05Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"In previous commit the first use of meson.can_run_host_binaries() was\nintroduced. This is a guard around compiler.run() to ensure it's\nactually possible to execute the provided.\n\nIn other places we've been having the same issue, but here `not\nmeson.is_cross_build()` is used as guard. This does the trick, but it\nalso prevents the code from running even when an exe_wrapper is\nconfigured.\n\nSwitch to using meson.can_run_host_binaries() here as well.\n\nThere is another place left that still uses `not\nmeson.is_cross_build()`, but here it's a guard around fs.exists(). That\nfunction will always run on the build machine, so checking for\ncross-compilation is still in place here.\n\nSigned-off-by: Toon Claes \n---\n meson.build | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/meson.build b/meson.build\nindex 95348e69a4..00ad8a5c60 100644\n--- a/meson.build\n+++ b/meson.build\n@@ -1492,7 +1492,7 @@ if not has_bsd_sysctl\n endif\n endif\n\n-if not meson.is_cross_build() and compiler.run('''\n+if meson.can_run_host_binaries() and compiler.run('''\n #include \n\n int main(int argc, const char **argv)\n--\n2.52.0\n"},{"id":"531624","messageId":"87ms3zwr6h.fsf@iotcl.com","threadId":"64565","inReplyTo":"aS9LvvjW7mZStceJ@pks.im","subject":"Re: [PATCH 2/2] meson: only detect ICONV_OMITS_BOM if possible","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-03T14:55:34Z","receivedAt":"2025-12-03T14:55:54Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Patrick Steinhardt writes:\n\n> We have `not meson.is_cross_build()` in a different location to guard a\n> call to `compiler.run()`. But `can_run_host_binaries()` is the better\n> way to test for this condition, as it allows the host to plug in a\n> wrapper (e.g. QEMU or WINE) that _would_ allow it to execute binaries of\n> the target host.\n>\n> `can_run_host_binaries()` is available since Meson 0.55, and we target\n> a version >=0.61.0. So should we maybe convert that other callsite to\n> use `can_run_host_binaries()` in a separate commit?\n\nI've sent \"PATH 3/2\" on top of this series. I've found two occurrences\nof `not meson.is_cross_compile()` but only replaced one, because the\nother is used to guard `fs.exists()` which (as far as I can tell) always\nruns on the build machine.\n\n-- \nCheers,\nToon\n"},{"id":"531644","messageId":"aTEnIOjhi_XtHdX8@pks.im","threadId":"64565","inReplyTo":"20251203145331.621529-1-toon@iotcl.com","subject":"Re: [PATCH 3/2] meson: use is_cross_build() where possible","fromName":"Patrick Steinhardt","fromEmail":"ps@pks.im","sentAt":"2025-12-04T06:16:00Z","receivedAt":"2025-12-04T06:16:07Z","isPatch":true,"sender":{"key":"ps@pks.im","avatar":"https://avatars.githubusercontent.com/u/4056630?v=4"},"body":"On Wed, Dec 03, 2025 at 03:53:31PM +0100, Toon Claes wrote:\n> In previous commit the first use of meson.can_run_host_binaries() was\n> introduced. This is a guard around compiler.run() to ensure it's\n> actually possible to execute the provided.\n> \n> In other places we've been having the same issue, but here `not\n> meson.is_cross_build()` is used as guard. This does the trick, but it\n> also prevents the code from running even when an exe_wrapper is\n> configured.\n> \n> Switch to using meson.can_run_host_binaries() here as well.\n> \n> There is another place left that still uses `not\n> meson.is_cross_build()`, but here it's a guard around fs.exists(). That\n> function will always run on the build machine, so checking for\n> cross-compilation is still in place here.\n\nThanks! This series looks good to me, including this patch.\n\nPatrick\n"},{"id":"531794","messageId":"3tucvydzaelj2mngkocb75l52nssxkkdtt3dj4paviatd3uvnc@u2sy4vig7owz","threadId":"64565","inReplyTo":"20251202-toon-cross-compile-v1-0-cabc8bce529f@iotcl.com","subject":"Re: [PATCH 0/2] Few fixes for cross-compiling with Meson","fromName":"Carlo Marcelo Arenas Belón","fromEmail":"carenas@gmail.com","sentAt":"2025-12-07T10:17:35Z","receivedAt":"2025-12-07T10:17:38Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Tue, Dec 02, 2025 at 11:48:07AM -0800, Toon Claes wrote:\n> I was cross-compiling for s390x.\n\nJust to clarify, you mean Linux on IBM Z/LinuxOne, not 64bit ZOS/ZVM, right?\n\nCarlo\n"},{"id":"531836","messageId":"874iq1vxwt.fsf@iotcl.com","threadId":"64565","inReplyTo":"3tucvydzaelj2mngkocb75l52nssxkkdtt3dj4paviatd3uvnc@u2sy4vig7owz","subject":"Re: [PATCH 0/2] Few fixes for cross-compiling with Meson","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-08T14:41:22Z","receivedAt":"2025-12-08T14:41:36Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Carlo Marcelo Arenas Belón writes:\n\n> On Tue, Dec 02, 2025 at 11:48:07AM -0800, Toon Claes wrote:\n>> I was cross-compiling for s390x.\n>\n> Just to clarify, you mean Linux on IBM Z/LinuxOne, not 64bit ZOS/ZVM,\n> right?\n\nI'm sorry, I'm not aware of the correct terminology here.\n\nIf I run file(1) on the compiled binary, I'm getting:\n\n ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV),\n dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0\n\nAnd readelf(1) says:\n\n ...\n OS/ABI: UNIX - System V\n ...\n Machine: IBM S/390\n ...\n\nAnd the toolchain used was installed from:\n\n https://aur.archlinux.org/packages/s390x-z13-glibc-bleeding-edge-toolchain\n\nI hope that clarifies it?\n\n-- \nCheers,\nToon\n"},{"id":"531865","messageId":"CAPUEspjifD8MYp6UR4pE91OqcJQdFafpeG8zNo1kfdxhnch_3A@mail.gmail.com","threadId":"64565","inReplyTo":"874iq1vxwt.fsf@iotcl.com","subject":"Re: [PATCH 0/2] Few fixes for cross-compiling with Meson","fromName":"Carlo Arenas","fromEmail":"carenas@gmail.com","sentAt":"2025-12-09T00:44:05Z","receivedAt":"2025-12-09T00:44:18Z","isPatch":true,"sender":{"key":"carenas@gmail.com","avatar":"https://avatars.githubusercontent.com/u/76036?v=4"},"body":"On Mon, Dec 8, 2025 at 6:41 AM Toon Claes wrote:\n>\n> Carlo Marcelo Arenas Belón writes:\n>\n> > On Tue, Dec 02, 2025 at 11:48:07AM -0800, Toon Claes wrote:\n> >> I was cross-compiling for s390x.\n> >\n> > Just to clarify, you mean Linux on IBM Z/LinuxOne, not 64bit ZOS/ZVM,\n> > right?\n>\n> I'm sorry, I'm not aware of the correct terminology here.\n\nIBM marketing doesn't make it easier, but yes IBM mainframes can run\nmultiple OS, and I have to admit I was kind of surprised to read we\nhad a working meson cross compilation for Z/OS, because I know that at\nleast cmake has issues even building natively.\n\n> If I run file(1) on the compiled binary, I'm getting:\n>\n> ELF 64-bit MSB pie executable, IBM S/390, version 1 (SYSV),\n> dynamically linked, interpreter /lib/ld64.so.1, for GNU/Linux 3.2.0\n\nSo this is 64-bit Big Endian linux for the s390x architecture (likely\ncompatible with z13 or higher CPUs)\n\nI happen to have one of those under the desk running RHEL9/s390x, so\nwill be happy to test your crosscompiled binaries, assuming it is as\nsimple as installing them somewhere and running something like `make\ntest`\n\nCarlo\n"},{"id":"532041","messageId":"87ikedgtpb.fsf@iotcl.com","threadId":"64565","inReplyTo":"CAPUEspjifD8MYp6UR4pE91OqcJQdFafpeG8zNo1kfdxhnch_3A@mail.gmail.com","subject":"Re: [PATCH 0/2] Few fixes for cross-compiling with Meson","fromName":"Toon Claes","fromEmail":"toon@iotcl.com","sentAt":"2025-12-11T11:10:24Z","receivedAt":"2025-12-11T11:10:43Z","isPatch":true,"sender":{"key":"toon@iotcl.com","avatar":"https://avatars.githubusercontent.com/u/121621?v=4"},"body":"Carlo Arenas writes:\n\n> I happen to have one of those under the desk running RHEL9/s390x, so\n> will be happy to test your crosscompiled binaries, assuming it is as\n> simple as installing them somewhere and running something like `make\n> test`\n\nThanks for the offer, but I don't think it's needed at the moment.\n\n-- \nCheers,\nToon\n"}]}