Implications of QEMU binfmt transparent emulation for builds

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

Hey,

I'm starting to play with mixing native and emulated builds with the
Guix Build Coordinator again. I did do this many months ago, but at that
time, there wasn't support for targeting retries across a range of
machines, to help avoid blockages due to QEMU issues.

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?

I'd like the Guix Build Coordinator agents to be able to report the
configuration of the machine at the time builds happen, so maybe once
that's a feature, and QEMU support can be detected, then it'll be
possible to look for cases where a change in QEMU support affects the
build result.

I've been thinking about this lately because I'd like to maybe use QEMU
to help build things for aarch64-linux and armhf-linux, but I don't want
to do something that could impact x86_64-linux derivations building for
other architectures (which guix.cbaines.net does do).

Thanks,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]