Meson recipe generates meson.cross.template with ``` [host_machine] system = '${SDK_OS}' cpu_family = '${@meson_cpu_family("SDK_ARCH", d)}' cpu = '${SDK_ARCH}' endian = '${@meson_endian("SDK", d)}' ``` Which results in `host_machine.cpu_family()` returning `x86_64` when cross compiling for `aarch64` on `x86_64`. Looking at Scarthgap it seems the `:class-native` has been fixed but `:class-nativesdk` still produces an invalid config.
Hello, Thanks for the report. Can you send a patch to fix the remaining problems? Can you also add a test case. Let me know if you need help. Rand for the YP bug review
Note that the sdk test case 'buildepoxy' should be building Meson code already.
https://git.yoctoproject.org/poky/tree/meta/lib/oeqa/sdk/cases/buildepoxy.py
I dug a little. The report is correct: the _cross_ file that describes the _host_ (that is, the MACHINE) describes the SDK configuration. This isn't trivial to fix (with s/SDK/HOST) because in meson-nativesdk, HOST _is_ SDK. Instead we need to extend the meson-setup.py which takes the environment configuration and updates the meson.cross file. The tests work because we don't verify that Meson is reading the right values, and libepoxy (which is our real world meson test case) doesn't care. I have partial changes so far, help testing would be much appreciated.
So if I understood correctly the issue here is that Yocto uses the meson.cross for building for the SDK and then installs that same meson.cross file there?
Not quite - nativesdk-meson ships a meson.cross file but it's wrong because when that file is created it _cannot_ know what the target is.
It needs nicer commit message, but https://git.yoctoproject.org/poky-contrib/log/?h=ross/mesonsdk is what I have so far. Testing would be appreciated but I believe it works (because I made the test suite check for this).
Patches on the list.
Patches were broken.
I think this is fixed with oe-core 0b882df19b5c339d2e7e00f56136afa890404f7b.