Why
building-on in contrib/guix/toolchains.scm reads (%current-system) once, when the module is loaded. guix shell loads the manifest before it applies --system, so the value is the system of the machine that runs the build, not the system that Guix builds for.
So a build with ADDITIONAL_GUIX_ENVIRONMENT_FLAGS="--system=aarch64-linux" on an x86_64 machine (for example with qemu-binfmt-service-type, to get an aarch64 build machine) configures the aarch64 cross toolchain with --build=x86_64-guix-linux-gnu. gcc-cross-sans-libc then fails to configure:
checking for CET support... configure: error: compiler and assembler with CET support are required for --enable-cet
What changes
building-on becomes a procedure, and its three call sites call it. Guix then computes the triplet for each derivation, under the system that the derivation is built for.
How I checked
- On master,
HOST=x86_64-linux-gnu guix shell -n --system=aarch64-linux -m contrib/guix/linux_static.scm(withtoolchains.scmon the load path, asguix-builddoes) givesgcc-cross-sans-libcwith--build=x86_64-guix-linux-gnu. With this PR it gives--build=aarch64-guix-linux-gnu. That is the same derivation thatguix build -d --system=aarch64-linuxgives on master. - Native builds (no
--system): the toolchain derivations fromlinux_static.scmandmanifest_gui.scmare identical on master and with this PR. So this PR does not change release builds. - With this PR, an emulated aarch64 build of
x86_64-linux-gnuon x86_64 built the whole cross toolchain and the non-GUI binaries. The GUI environment then failed in the tests ofpython-pylint(timeout under emulation) andmaturin(snapshot mismatch). These packages have no aarch64 substitutes at the pinned Guix commit, and the failures are not related to this change.