This requires doing a lot more backflipping to accept the musl key because it frankly should probably be replaced with something newer (at least since 2023, if not since 2013).
I had two MIPS-related hiccups with this:
- the musl-upstream `musl-gcc` wrapper script has a bug that drops compiler arguments (patch included here; hopefully we can remove in the future?)
- QEMU couldn't run the resulting MUSL binaries until I applied an update to my binfmt magic/mask (https://bugs.debian.org/1041597, bb0811e353) - it also runs just fine on real musl hardware
This adds a `.host-arch` symlink to build output; this doesn't get committed (for hopefully obvious reasons), but allows for things like `CMD` and `update.sh` to have a known-effective target for testing the output further in some way.
This was a mapping we already had thanks to `ARCH_TEST`, so I've also reordered our builds such that they're grouped by "host" architecture and sorted by "preference"/compatibility (with the goal that we get a more "correct" `.host-arch` symlink).
This is pulled in automatically via `gnupg`, and moved from `Recommends` to `Depends` in 99474ad900, which has been part of `src:gnupg2` since 2.1.21-4 (and every supported version of both Debian _and_ Ubuntu have 2.2.x 😇).
The intent of the previous implementation was to avoid libc, but it turns out that just invoking a syscall without libc is complicated (see https://github.com/docker-library/hello-world/pull/62#issuecomment-568573535 for details).
On the other hand, my personal machine can cross-compile all of musl in ~30s per architecture, which is pretty reasonable, and the resulting binary sizes are only around ~10k each, and I was able to do so successfully for every architecture we currently support.
Tianon Gravi