mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.63k stars 1.63k forks source link

"Can not run test applications in this cross environment" not consistent with meson.can_run_host_binaries() #13841

Open smcv opened 2 weeks ago

smcv commented 2 weeks ago

Describe the bug Similar to #12017, when doing a native build in a Debian armhf chroot (32-bit arm-linux-gnueabihf with ARMv7 baseline) on an aarch64 machine, compiler.run() can fail with Can not run test applications in this cross environment, even though meson.can_run_host_binaries() previously returned true.

https://tests.reproducible-builds.org/debian/logs/unstable/armhf/accountsservice_23.13.9-7.build2.log.gz is an example of this causing a build failure during automated testing.

To Reproduce In an armhf chroot/container on an an aarch64 machine, without using linux32 or similar personality wrapper:

project('foo', 'c')
if meson.is_cross_build()
    warning('cross build detected')
endif
if meson.can_run_host_binaries()
    meson.get_compiler('c').run('whatever')
endif

(Or set up the above with linux64 meson setup _build)

Workaround (1) Set a personality so that the kernel pretends to be running on a 32-bit machine, for example:

linux32 meson setup _build

The 32-bit chroots on Debian porterboxes and official Debian buildds do this automatically, but it is not guaranteed, and in particular https://tests.reproducible-builds.org/debian does not guarantee to do so.

Workaround (2)

$ cat > workaround.txt <<EOF
[properties]
needs_exe_wrapper = false
EOF
$ meson setup --native-file workaround.txt _build

Expected behavior I expected the sample project to configure successfully. (Obviously the invalid C code whatever fails to compile, but in this minimal reproducer that has no practical effect.)

It would also be understandable, although considerably less good, if meson.is_cross_build() returned true and meson.can_run_host_binaries() returned false.

system parameters

smcv commented 2 weeks ago

I don't think the equivalent of #12080 would be a correct fix for this in the case of aarch64 and arm, because most aarch64 CPUs support 32-bit ARM instructions, but unlike their equivalents in the x86 and mips worlds, that is not an architectural guarantee and according to Wikipedia, the ARM Cortex-A34 is an example of an aarch64-only CPU that is not backward compatible with 32-bit ARM instructions.

smcv commented 2 weeks ago

Another workaround for this issue is to use a --native-file containing:

[properties]
needs_exe_wrapper = false

Could Meson perhaps automatically behave as if needs_exe_wrapper = false whenever it is doing a native build?