Re: Implications of QEMU binfmt transparent emulation for builds

["Ludovic Courtès" <ludo@gnu.org>]

Hi Chris,

Christopher Baines <mail@cbaines.net> skribis:

> Anyway, something that's been on my mind regarding QEMU and builds is
> how well this matches up with building natively. In particular, I'm
> concerned that there are some derivations that will build on system A
> with some QEMU configuration allowing binaries for system B to be run,
> but won't build if that QEMU support wasn't there. I think there's also
> a chance that you could have a derivation for system A that builds on a
> system with QEMU support for system B, but then wouldn't build natively
> on system B.
>
> I think the first scenario is more likely, mainly because I wonder if
> this happens with cross built packages. If the package attempts to run
> software built for the target system, that will work if there's QEMU
> support there for that target system, but not if that QEMU support is
> lacking.
>
> This is just a theory at this point, I at least don't know of any cases
> of this happening, but I also haven't been looking. Any ideas?

We had concrete problems that manifested as CMake failing to find a
compiler when running emulated (emulated AArch64/ARMv7 on x86_64),
whereas it would find the compiler when running natively:

  https://issues.guix.gnu.org/43513

That’s the worst case: an issue showing up in emulated builds in a
deterministic fashion, and never happening on actual hardware.

Thanks,
Ludo’.