What is the difference between `aarch64-apple-darwin` and `aarch64-darwin` and why are they incompatible?

I tried to install qmk via nix-env on my M1 MacBook just now, and I’m seeing a behaviour I can’t quite understand:

$ nix-env --version
nix-env (Nix) 2.13.3
$ nix-env -iA unstable.qmk
installing 'qmk-1.1.2'
error: Package ‘avr-stage-final-gcc-wrapper-8.5.0’ in /nix/store/1mcdyrcp9s1i5pxvn1cslvvkc0ndd495-unstable/unstable/pkgs/build-support/cc-wrapper/default.nix:613 is not available on the requested hostPlatform:
         hostPlatform.config = "aarch64-apple-darwin"
         package.meta.platforms = [
           "i686-cygwin"
           "x86_64-cygwin"
           "x86_64-darwin"
           "i686-darwin"
           "aarch64-darwin"
           "armv7a-darwin"
           "i686-freebsd13"
           "x86_64-freebsd13"
           "x86_64-solaris"
           "aarch64-linux"
           "armv5tel-linux"
           "armv6l-linux"
           "armv7a-linux"
           "armv7l-linux"
           "i686-linux"
           "m68k-linux"
           "microblaze-linux"
           "microblazeel-linux"
           "mipsel-linux"
           "mips64el-linux"
           "powerpc64-linux"
           "powerpc64le-linux"
           "riscv32-linux"
           "riscv64-linux"
           "s390-linux"
           "s390x-linux"
           "x86_64-linux"
           "aarch64-netbsd"
           "armv6l-netbsd"
           "armv7a-netbsd"
           "armv7l-netbsd"
           "i686-netbsd"
           "m68k-netbsd"
           "mipsel-netbsd"
           "powerpc-netbsd"
           "riscv32-netbsd"
           "riscv64-netbsd"
           "x86_64-netbsd"
           "i686-openbsd"
           "x86_64-openbsd"
           "x86_64-redox"
         ]
         package.meta.badPlatforms = [
           "aarch64-darwin"
         ]
       , refusing to evaluate.

       a) To temporarily allow packages that are unsupported for this system, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_UNSUPPORTED_SYSTEM=1

        Note: For `nix shell`, `nix build`, `nix develop` or any other Nix 2.4+
        (Flake) command, `--impure` must be passed in order to read this
        environment variable.

       b) For `nixos-rebuild` you can set
         { nixpkgs.config.allowUnsupportedSystem = true; }
       in configuration.nix to override this.

       c) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
         { allowUnsupportedSystem = true; }
       to ~/.config/nixpkgs/config.nix.
(use '--show-trace' to show detailed location information)

This is the first time I’m seeing this, and I don’t think I ever heard of aarch64-apple-darwin before. What is the difference between aarch64-apple-darwin and aarch64-darwin? Are they really incompatible? Could I manually override my hostPlatform to be aarch64-darwin again?

All I could find on this is an old GitHub Issue about nix supporting aarch64-darwin. aarch64-apple-darwin is only mentioned once with regards to LLVM. Might that be related to my issue here?

1 Like

aarch64-apple-darwin is just the triple used for the platform.

$ nix eval nixpkgs#legacyPackages.aarch64-darwin.stdenv.hostPlatform.config
"aarch64-apple-darwin"

That’s nothing to do with your problem. The problem is that this qmk derivation seems to be doing some weird cross compilation stuff and I guess the way it’s implemented in nixpkgs right now just isn’t compatible with macOS. I believe using GCC as a cross compiler on macOS was only recently fixed with GCC 11, and that qmk derivation is using GCC 8.

2 Likes

The stuff is not really “weird” — it’s mostly the same stuff that is used by simavr (although in that case the package is specified in all-packages.nix; maybe qmk should be changed to use something like that too, so that it would be possible to override these arguments).

Unfortunately, I don’t have any Apple hardware, so can’t really debug this. Apparently the simavr package does get built for x86_64-darwin, but not for aarch64-darwin; so maybe pkgsCross.avr.buildPackages.gcc has the same problem as pkgsCross.avr.buildPackages.gcc8?

As for why gcc8 is used in qmk, the issue is that GCC versions after 8 have some regressions that result in the generated code being larger; for QMK this often means that the compiled firmware does not fit into the (very small) flash of typical AVR MCUs like ATmega32U4. Although it seems that some more recent GCC versions have some of those regressions fixed (in particular, GCC 13 as provided by Arch Linux can be used to build the qmk-dfu bootloader, which must fit into 4 KiB), so maybe it could be possible to switch qmk to pkgsCross.avr.buildPackages.gcc in the future. This would also fix another problem — currently qmk is not available in the binary cache for x86_64-darwin, because the pkgsCross.avr.buildPackages.gcc8 package fails to build on Hydra due to excessive log output size (the build can actually complete in the GitHub CI environment and seems to provide a working compiler, but the amount of compiler warnings generated during the build causes the failure on Hydra).