[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 <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’.