[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implications of QEMU binfmt transparent emulation for builds

From: Ludovic Courtès
Subject: Re: Implications of QEMU binfmt transparent emulation for builds
Date: Wed, 10 Mar 2021 11:47:55 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Hi Chris,

Christopher Baines <> 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:

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]