_meson_create_cross_file() sets needs_exe_wrapper to true, but there seems to be no way to set exe wrapper program itself (exe_wrapper variable in binaries section). IMHO there should be a way to set it via environment. Reproducible: Always Steps to Reproduce: Try to crossbuild dev-libs/gobject-introspection. Actual Results: Build fails with: Cannot use target g-ir-compiler as a generator because it is built for the host machine and no exe wrapper is defined or needs_exe_wrapper is true.
Just FYI, we have a work around for this in our chromiumos code: https://chromium.googlesource.com/chromiumos/overlays/eclass-overlay/+/refs/heads/main/eclass/meson.eclass#155
*** Bug 850895 has been marked as a duplicate of this bug. ***
Hello. So, I was trying to crosscompile dev-cpp/benchmark[tools] and it seems to use scipy, and it seems to use numpy. Setup: amd64 main system, aarch64-unknown-linux-gnueabi crossdev -s4 At numpy I got a configuration problem: ``` Checking for function "strtold_l" : YES Compiler for C supports arguments -O3: YES ../numpy-2.2.3/numpy/_core/meson.build:408:46: ERROR: Can not run test applications in this cross environment. A full log can be found at /usr/aarch64-unknown-linux-gnueabi/tmp/portage/dev-python/numpy-2.2.3/work/numpy-2.2.3-python3_12/meson-logs/meson-log.txt * ERROR: dev-python/numpy-2.2.3::gentoo failed (compile phase): * Wheel build failed * ``` Respected Sam James in IRC explained a temporary solution via patching the meson.eclass . It consist of creating a patch and making portage apply it every time a repo is synced. 1. Get an execution wrapper and maybe setup binfmt_misc (optional for this). I wrote an article about qemu-wrapper for crossdev's "chroot". Different people from IRC #gentoo-toolchain such as `sam_` and `amonakov` helped a lot for sure. Check the wrapper at https://wiki.gentoo.org/wiki/Crossdev/Testing_packages_via_qemu and some basic instructions related. 2. Make `meson.eclass` to use the wrapper So, here's my simple patch with no logic: ``` diff --git a/eclass/meson.eclass b/eclass/meson.eclass index a2bc5537e..e3cf7fcc9 100644 --- a/eclass/meson.eclass +++ b/eclass/meson.eclass @@ -167,6 +167,7 @@ _meson_create_cross_file() { pkg-config = '$(tc-getPKG_CONFIG)' strip = $(_meson_env_array "$(tc-getSTRIP)") windres = $(_meson_env_array "$(tc-getRC)") + exe_wrapper = '/usr/aarch64-unknown-linux-gnueabi/qemu-wrapper' [built-in options] c_args = $(_meson_env_array "${CFLAGS} ${CPPFLAGS}") ``` As you can see, it's a hardcoded path for this example, therefore no logic. 3. Make portage autopatch the gentoo repo Place the patch at `/etc/portage/repo-patches/gentoo/meson_eclass_exe_wrapper.patch` , then `cd /tmp && git clone https://github.com/thesamesam/sam-gentoo-scripts` `mkdir /etc/portage/repo.postsync.d` `cp ./sam-gentoo-scripts/sync/repo-patches /etc/portage/repo.postsync.d/repo-patches` Then comment/uncomment some LOC in the script at `/etc/portage/repo.postsync.d/repo-patches` so that you can regenerate cache. Since I had only portage, I've chosen a line with `egencache` . That's it right now. Maybe a patch with using a environment variable would be better
