Recognize get_cpu_value "darwin_arm64"

[aherrmann]

On an M1 Mac get_cpu_value will return darwin_arm64 instead of darwin.
This PR adapts our platform constraint detection to take that case into account.

Note, if bazel runs as an x86_64 binary under Rosetta, then get_cpu_value will still report darwin.
So, under Rosetta this will consistently use x86_64 constraints.

This also removes an unused instance of get_cpu_value in the Go toolchain.

[AleksanderGondek]

Looks good to me...
In regards to M11 CI issues - I do not have hardware to investigate

[YorikSar]

I've tried running tests on my machine with Rosetta, got the same errors for tests. From logs, both python2-test and python3-test failed because of wrong Python executable (or rather symlink):

 % cat /private/var/tmp/_bazel_tweag/27194dc9430cdb4660c09c5ecb36f088/execroot/io_tweag_rules_nixpkgs/bazel-out/darwin-py2-fastbuild/testlogs/external/nixpkgs_python_configure_test/python2-test/test.log
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from @nixpkgs_python_configure_test//:python2-test
-----------------------------------------------------------------------------
Python interpreter is not provided by the toolchain.
Expected: '/nix/store/k8z8arjfcnap8l8vry9vmw9dfdi9vsbq-python-2.7.18/bin/python'
Actual:   '/nix/store/k8z8arjfcnap8l8vry9vmw9dfdi9vsbq-python-2.7.18/bin/python2'.

 % cat /private/var/tmp/_bazel_tweag/27194dc9430cdb4660c09c5ecb36f088/execroot/io_tweag_rules_nixpkgs/bazel-out/darwin-fastbuild/testlogs/external/nixpkgs_python_configure_test/python3-test/test.log 
exec ${PAGER:-/usr/bin/less} "$0" || exit 1
Executing tests from @nixpkgs_python_configure_test//:python3-test
-----------------------------------------------------------------------------
Python interpreter is not provided by the toolchain.
Expected: '/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/bin/python'
Actual:   '/nix/store/x0fw0l4d6zwgfdwbpp23iwhm3c6a1hh3-python3-3.9.6/bin/python3'.

I don't quite understand how that could happen. Both python and python2 symlinks point to python2.7 binary, for example. It means that it's not just something following the symlink or smth.

I'll check the failure in examples a bit later.

---

Without Rosetta, when I specified aarch64-darwin in shell.nix, I got these errors:

ERROR: While resolving toolchains for target @rules_sh//sh/posix:make_variables: no matching toolchains found for types @rules_sh//sh/posix:toolchain_type
ERROR: Analysis of target '//docs:update-readme' failed; build aborted: no matching toolchains found for types @rules_sh//sh/posix:toolchain_type

I guess, rules_sh isn't ready for ARM yet.

[YorikSar]

In examples with Rosetta and nix:

• cc segfaults for seemingly no reason (although on CI it failed to compile somehow)
• cc_with_deps works just fine
• go works fine
• python throws ModuleNotFoundError: No module named 'cv2'
• java fails with

ERROR: /private/var/tmp/_bazel_tweag/c30554a34370f0f38e20aa05121a8b82/external/bazel_tools/tools/jdk/BUILD:29:19: While resolving toolchains for target @bazel_tools//tools/jdk:current_java_runtime: no matching toolchains found for types @bazel_tools//tools/jdk:runtime_toolchain_type

With aarch64-darwin in shell.nix files:

• cc fails with

ERROR: /private/var/tmp/_bazel_tweag/c97a5d687d8a262c6a2a40916956f782/external/local_config_cc/BUILD:48:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'darwin_arm64'

• everything else is the same.

Overall it seems like something isn't right with more complex toolchains there.

[ryanbujnowicz]

Thanks for looking into this @aherrmann . I recently got an M1-based Macbook and I'm interested in getting this toolchain working. I was hacking around with your arm64 branch today and noticed:

• os:linux was still showing up in the exec_compatible_with attribute of my cc-toolchain-darwin_arm64 cc toolchain. I think this is because the value of cpu at this line gets stomped on line 18 so it's falling back to the os:linux default.
• Does similar support for darwin_arm64 need to happen at this line?

Thanks again.

[aherrmann]

@ryanbujnowicz Thank you for looking into this! Yes, I think you're right on all accounts. I've pushed changes to fix it.
I've also used this opportunity to align the POSIX toolchain constraints with the other toolchains. (It's a bit of a special case because it doesn't set target constraints, see note here).

[aherrmann]

Rebased on master

[fricklerhandwerk]

I cannot meaningfully test this, don't have M1. Removed myself from reviewers.

[andyscott]

I was able to get this working, but I had to make one additional tweak/hack to work around codesign_allocate issues (NixOS/nixpkgs#148282).

My toolchain is configured as follows:

In WORKSPACE.bazel:

nixpkgs_cc_configure(
    name = "nixpkgs_config_cc",
    repository = "@nixpkgs",
    # We presently use our own nix file here so we can patch in a workaround for
    # https://github.com/NixOS/nixpkgs/pull/148282. See the header of cc.nix for
    # more details on our tweak.
    nix_file = "//tools/toolchains/cc:cc.nix",
)

In tools/toolchains/cc/cc/nix:

let

  # Notes:
  #
  # 1. This whole file is just a rip of the cc expression from rules_nixpkgs, here:
  #    https://github.com/tweag/rules_nixpkgs/blob/master/toolchains/cc/cc.nix
  #
  # 2. Modification -- We add cctools to path so that codesign_allocate can be found in
  #    the postLinkSignHook phase on OSX M1 machines. This is a hack and likely can be
  #    removed onced https://github.com/NixOS/nixpkgs/pull/148282 is resolved.
  #

  pkgs = import <nixpkgs> { config = { }; overlays = [ ]; };

  darwinCC =
    # Work around https://github.com/NixOS/nixpkgs/issues/42059.
    # See also https://github.com/NixOS/nixpkgs/pull/41589.
    pkgs.runCommand "bazel-nixpkgs-cc-wrapper"
      {
        buildInputs = [ pkgs.makeWrapper ];
      }
      (''
        mkdir -p $out/bin
        for i in ${pkgs.stdenv.cc}/bin/*; do
          ln -sf $i $out/bin
        done
        # Override cc
        rm -f $out/bin/cc $out/bin/clang $out/bin/clang++
        makeWrapper ${pkgs.stdenv.cc}/bin/cc $out/bin/cc \
      '' +
      # Pipe tweak: see Note 1 at the top of this file!
      ''  --prefix PATH : ${pkgs.lib.makeBinPath [ pkgs.darwin.cctools ]} \
      '' +
      ''  --add-flags \
            "-Wno-unused-command-line-argument \
            -isystem ${pkgs.llvmPackages.libcxx}/include/c++/v1 \
            -F${pkgs.darwin.apple_sdk.frameworks.CoreFoundation}/Library/Frameworks \
            -F${pkgs.darwin.apple_sdk.frameworks.CoreServices}/Library/Frameworks \
            -F${pkgs.darwin.apple_sdk.frameworks.Security}/Library/Frameworks \
            -F${pkgs.darwin.apple_sdk.frameworks.Foundation}/Library/Frameworks \
            -L${pkgs.libcxx}/lib \
            -L${pkgs.darwin.libobjc}/lib"
      '');
in
pkgs.buildEnv {
  name = "bazel-nixpkgs-cc";
  ignoreCollisions = true;
  # XXX: `gcov` is missing in `/bin`.
  #   It exists in `stdenv.cc.cc` but that collides with `stdenv.cc`.
  paths =
    if pkgs.stdenv.isDarwin then
      [ (pkgs.overrideCC pkgs.stdenv darwinCC).cc pkgs.darwin.binutils ]
    else
      [ pkgs.stdenv.cc pkgs.binutils ];

  pathsToLink = [ "/bin" ];
}

[aherrmann]

@andyscott Thanks for testing! Yes, indeed, full M1 support requires some more changes to the cc toolchain. The focus of this PR was solely on the get_cpu_info detection aspect. You can take a look at this PR for a full M1 configuration. The goal is to migrate the remaining needed changes to rules_nixpkgs in the future.

[avdv]

LGTM, but due to lack of an M1 machine I could not test this myself.

[avdv]

Tested on an M1 successfully:

✔️ all tests passed.
✔️ all examples build (with Nix)
✔️ all examples produced native executables (Mach-O 64-bit executable arm64) [where applicable]
✔️ all examples ran