Apple Silicon toolchain support

I just got an M1 MacBook Pro today, and am looking into how to use this project to generate arm64 binaries (for the record: everything works fine using this project to generate x86_64 binaries, which then run under Rosetta).
In the Apple Developer Documentation, they make it out to be as simple as passing a -target flag to the C compiler, though I'm sure it'll be more work to do the same thing in Bazel.
https://developer.apple.com/documentation/apple-silicon/building-a-universal-macos-binary
Have anyone put thought or time into how this project might be extended to support generating arm64 binaries on M1 Macs? I'm probably going to be spending some time getting this working, and I'd love any tips, ideas, or places to start.

I thought about this a bit while working on #85.
I think there are actually two separate things:

using clang compiled for x86_64 to produce binaries for arm64 (i.e. cross compiling)
using clang compiled for arm64 to produce binaries for arm64

I think the first can be done with the feature #85 adds but I also think it's really the second thing that you'd want when running macOS on ARM (so that clang doesn't needlessly have to run through Rosetta).

To add support for arm64 darwin host platforms, we'd need to:

update parts of configure.bzl that hardcode the CPU constraints to x86_64

we can either parameterize these over the current CPU or just add entries for every host CPU that we want to support (as we do for OSes – we always have macOS and linux toolchains regardless of the OS of the host platform; we let toolchain resolution pick the right one)
I'm inclined to just add entries for all the host CPUs we want to support since I don't know of a good way to determine the CPU type of the host from a repo rule (an alias on a select on the CPU or just running arch are the two ways that come to mind, both of which seem bad); users who aren't using toolchain resolution yet won't have their setups broken since we can add the appropriate entries to the toolchain_suite

update cc_toolchain_config to take a host_cpu arg

at a glance, I think this only really affects the host_system_name, and the default target_system_name, target_cpu, abi_version, and abi_libc_version

sysroot.bzl might need some changes depending on whether the sysroots for arm64 macOS installs are any different
have llvm_distributions.bzl grow entries for arm64 macOS (more on this below)
change BUILD.tpl to match configure.bzl

And I think that should be about it.
I think the bigger obstacle right now is that LLVM doesn't publish binaries for arm64 macOS (even though it's definitely possible to build LLVM for arm64 macOS). This effectively means that you'd have to provide your own download URL to to llvm_toolchain.
Adding tests for this in CI will also be tricky since (afaik) GitHub Actions doesn't yet have ARM worker machines let alone macOS ARM worker machines but that's okay.

@jez I'm happy to try to put together these changes if you're willing to test (I don't have an arm64 macOS machine).

I’m more than happy to test! Do you have a sense of when you’d have time to work on this?
Also: I think that even being able to produce arm64 binaries would be an improvement, even if they were built by x86_64 clang. I see that #85 is a draft—is that something you’d like me to test? Or is there something else holding it back from landing?

Okay! I put together a thing that uses #85 to set up a toolchain for arm64 (still x86_64 based so it's cross-compiling).
It took a little doing; I'm not on macOS 11 so my sysroot didn't have the right stuff and it took me a while to realize that the ld that ships in LLVM releases doesn't have support for the tbd (TAPI) files that newer macOS SDKs ship. I ended up having to use lld as the linker; I'm not sure this is totally right:
        # newer macOS SDKs use `.tbd` files in their sysroots; `lld` has support for this
        # (on recent versions) but `ld` (that ships in the LLVM releases) does not
        #
        # so, we need to specify that we want to use `lld`
        #
        # historically, we have not done this for macOS by default because of incomplete
        # support for Mach-O in `lld` but newer version seem to have good support.
        "extra_linker_flags": ["-fuse-ld=lld"],

I'd love to know what Apple clang does (just the output of g++ -v -xc++ - <<<"int main() { }" on an M1 machine should give it away I think).
But anyways, with the above, it does get all the way through linking on my x86_64 macOS machine. I can't actually run the generated binaries but hopefully they do actually work 🤞.
I've attached the workspace I put together to this comment.

bazel run //:test --config=x86 to check that the regular old x86_64 -> x86_64 toolchain works, etc.
bazel build //:test --config=arm64 to make the x86_64 -> arm64 toolchain can generate binaries
bazel run //:test --config=arm64 to make sure the binaries emitted can actually run on arm64

In theory running bazel run //:test (without any --config to manually set the target platform) should pick up the arm64 toolchain and use it, depending on what constraints Bazel gives M1 machines. I have no idea how this interacts with Rosetta though; bazel build //:test --toolchain_resolution_debug should give us some hints.
workspace.zip

re: your other questions:
I should have time to try to get the arm64 -> arm64 toolchain working over the weekend; assuming ^ works, that should be fairly straight-forward. The trickiest part will probably be finding/building an arm64 LLVM toolchain to use.
#85 is still a draft because it builds on #75 which hasn't yet been merged and because it's missing some docs and polish; I wanted to solicit some feedback about some of the design choices in that PR before cleaning it up. It is more or less functional though.

I'd love to know what Apple clang does (just the output of g++ -v -xc++ - <<<"int main() { }" on an M1 machine should give it away I think).

Here's the output:
output.log
I'll test that workspace out now and see what happens.

Here's the output:
output.log

Thanks! Can you run /Library/Developer/CommandLineTools/usr/bin/ld -v also? I'm pretty sure it's just ld64 but just in case.

❯ /Library/Developer/CommandLineTools/usr/bin/ld -v
@(#)PROGRAM:ld  PROJECT:ld64-650.9
BUILD 13:09:13 May 28 2021
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
LTO support using: LLVM version 12.0.5, (clang-1<IP_ADDRESS>) (static support for 27, runtime is 27)
TAPI support using: Apple TAPI version 12.0.5 (tapi-1<IP_ADDRESS>)

is the @macos-11.3-sdk// repo basically the same set of files I have at /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk, judging from the output.log above?

yup, exactly

I had to grab it externally because I'm on an older version of macOS that doesn't have an SDK with the right stuff to build for arm64
but for host arm64 toolchains (as in arm64 -> arm64) we shouldn't actually need to grab it; like we do with the other host toolchains, we can just assume what's on the host system actually works when you're targeting the host system

~/stripe/sandbox/rrbutani-workspace   19s
❯ ./bazel run //:test --config=x86
Starting local Bazel server and connecting to it...
ERROR: /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/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'
ERROR: Analysis of target '//:test' failed; build aborted: Analysis of target '@local_config_cc//:toolchain' failed
INFO: Elapsed time: 69.390s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (16 packages loaded, 61 targets configured)
FAILED: Build did NOT complete successfully (16 packages loaded, 61 targets configured)

(I had to make a slight change to the repo, which is to make it use a script that has contents identical to this:
https://github.com/jez/ragel-bison-parser-sandbox/blob/master/bazel
because our company laptops prevent us from installing bazelisk) but otherwise the above is the result of running things.
Interestingly enough, that's the same error I get when trying to build a normal bazel project on my macbook. For example this tiny project shows the same problems.
bazel-test.zip

hmm
Does /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/external/local_config_cc/BUILD:48 look like:
cc_toolchain_suite(
    name = "toolchain",
    toolchains = {
        "k8|clang": ":cc-clang-linux",
        "darwin|clang": ":cc-clang-darwin",
        "k8": ":cc-clang-linux",
        "darwin": ":cc-clang-darwin",
    },
)

for you?

oh whoops, nvm; I totally missed that that's @local_config_cc

It's not clear to me why it's even analyzing @local_config_cc//:toolchain; can you post what bazel build //:test --toolchain_resolution_debug prints out?

It's not clear to me why it's even analyzing @local_config_cc//:toolchain; can you post what bazel build //:test --toolchain_resolution_debug prints out?

~/stripe/sandbox/rrbutani-workspace
❯ bazel build //:test --toolchain_resolution_debug
INFO: Build options --platforms and --toolchain_resolution_debug have changed, discarding analysis cache.

FAILED: Build did NOT complete successfully (0 packages loaded, 60 targets configured)

Also in your original post you mentioned that you have an x86_64 -> x86_64 setup working; did you have to manually set your host platform or change anything toolchain related to get that to work?

Also in your original post you mentioned that you have an x86_64 -> x86_64 setup working; did you have to manually set your host platform or change anything toolchain related to get that to work?

Yeah, overnight that seems to have stopped working. I can't explain that.

It's not clear to me why it's even analyzing @local_config_cc//:toolchain; can you post what bazel build //:test --toolchain_resolution_debug prints out?

~/stripe/sandbox/rrbutani-workspace
❯ bazel build //:test --toolchain_resolution_debug
INFO: Build options --platforms and --toolchain_resolution_debug have changed, discarding analysis cache.

FAILED: Build did NOT complete successfully (0 packages loaded, 60 targets configured)

That's odd; toolchain resolution happens exactly as we'd expected (it picks the x86 clang toolchain for macOS) but it still pulls in @local_config_cc 😕.
Can you try running bazel cquery 'deps(//:test)' --output=graph --config=x86? It should at least tell us what's pulling it in.
@local_config_cc//:toolchain shouldn't be broken though :-/

(actually the contents of /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/external/local_config_cc/BUILD would also be interesting to look at)

local_config_cc/BUILD

# Copyright 2016 The Bazel Authors. All rights reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#    http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

# This becomes the BUILD file for @local_config_cc// under non-BSD unixes.

package(default_visibility = ["//visibility:public"])

load(":cc_toolchain_config.bzl", "cc_toolchain_config")
load(":armeabi_cc_toolchain_config.bzl", "armeabi_cc_toolchain_config")
load("@rules_cc//cc:defs.bzl", "cc_toolchain", "cc_toolchain_suite")

licenses(["notice"])  # Apache 2.0

cc_library(
    name = "malloc",
)

filegroup(
    name = "empty",
    srcs = [],
)

filegroup(
    name = "cc_wrapper",
    srcs = ["cc_wrapper.sh"],
)

filegroup(
    name = "compiler_deps",
    srcs = glob(["extra_tools/**"], allow_empty = True) + [":builtin_include_directory_paths",
    ":cc_wrapper"],
)

# This is the entry point for --crosstool_top.  Toolchains are found
# by lopping off the name of --crosstool_top and searching for
# the "${CPU}" entry in the toolchains attribute.
cc_toolchain_suite(
    name = "toolchain",
    toolchains = {
        "darwin_arm64|clang": ":cc-compiler-darwin_arm64",
        "darwin_arm64": ":cc-compiler-darwin_arm64",
        "armeabi-v7a|compiler": ":cc-compiler-armeabi-v7a",
        "armeabi-v7a": ":cc-compiler-armeabi-v7a",
    },
)

cc_toolchain(
    name = "cc-compiler-darwin_arm64",
    toolchain_identifier = "local",
    toolchain_config = ":local",
    all_files = ":compiler_deps",
    ar_files = ":compiler_deps",
    as_files = ":compiler_deps",
    compiler_files = ":compiler_deps",
    dwp_files = ":empty",
    linker_files = ":compiler_deps",
    objcopy_files = ":empty",
    strip_files = ":empty",
    supports_param_files = 1,
    module_map = ":module.modulemap",
)

cc_toolchain_config(
    name = "local",
    cpu = "darwin_arm64",
    compiler = "clang",
    toolchain_identifier = "local",
    host_system_name = "local",
    target_system_name = "local",
    target_libc = "macosx",
    abi_version = "local",
    abi_libc_version = "local",
    cxx_builtin_include_directories = ["/Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/include",
    "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include",
    "/Library/Developer/CommandLineTools/usr/include",
    "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks",
    "/Library/Developer/CommandLineTools/usr/lib/clang/12.0.5/share",
    "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1"],
    tool_paths = {"ar": "/usr/bin/libtool",
        "ld": "/usr/bin/ld",
        "llvm-cov": "None",
        "cpp": "/usr/bin/cpp",
        "gcc": "cc_wrapper.sh",
        "dwp": "/usr/bin/dwp",
        "gcov": "/usr/bin/gcov",
        "nm": "/usr/bin/nm",
        "objcopy": "/usr/bin/objcopy",
        "objdump": "/usr/bin/objdump",
        "strip": "/usr/bin/strip"},
    compile_flags = ["-U_FORTIFY_SOURCE",
    "-fstack-protector",
    "-Wall",
    "-Wthread-safety",
    "-Wself-assign",
    "-fcolor-diagnostics",
    "-fno-omit-frame-pointer"],
    opt_compile_flags = ["-g0",
    "-O2",
    "-D_FORTIFY_SOURCE=1",
    "-DNDEBUG",
    "-ffunction-sections",
    "-fdata-sections"],
    dbg_compile_flags = ["-g"],
    cxx_flags = ["-std=c++0x"],
    link_flags = ["-undefined",
    "dynamic_lookup",
    "-headerpad_max_install_names"],
    link_libs = ["-lstdc++",
    "-lm"],
    opt_link_flags = [],
    unfiltered_compile_flags = ["-no-canonical-prefixes",
    "-Wno-builtin-macro-redefined",
    "-D__DATE__=\"redacted\"",
    "-D__TIMESTAMP__=\"redacted\"",
    "-D__TIME__=\"redacted\""],
    coverage_compile_flags = ["-fprofile-instr-generate",  "-fcoverage-mapping"],
    coverage_link_flags = ["-fprofile-instr-generate"],
    supports_start_end_lib = False,
)

# Android tooling requires a default toolchain for the armeabi-v7a cpu.
cc_toolchain(
    name = "cc-compiler-armeabi-v7a",
    toolchain_identifier = "stub_armeabi-v7a",
    toolchain_config = ":stub_armeabi-v7a",
    all_files = ":empty",
    ar_files = ":empty",
    as_files = ":empty",
    compiler_files = ":empty",
    dwp_files = ":empty",
    linker_files = ":empty",
    objcopy_files = ":empty",
    strip_files = ":empty",
    supports_param_files = 1,
)

armeabi_cc_toolchain_config(name = "stub_armeabi-v7a")

and the other one:
❯ bazel cquery 'deps(//:test)' --output=graph --config=x86
INFO: Build options --platforms and --toolchain_resolution_debug have changed, discarding analysis cache.
ERROR: /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/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'
ERROR: Analysis of target '//:test' failed; build aborted: Analysis of target '@local_config_cc//:toolchain' failed
INFO: Elapsed time: 0.791s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 61 targets configured)

❯ bazel cquery 'deps(//:test)' --output=graph --config=x86
INFO: Build options --platforms and --toolchain_resolution_debug have changed, discarding analysis cache.
ERROR: /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/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'
ERROR: Analysis of target '//:test' failed; build aborted: Analysis of target '@local_config_cc//:toolchain' failed
INFO: Elapsed time: 0.791s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 61 targets configured)

oh whoops; does it get any further if you add --keep_going?

wait ^ makes sense actually; there isn't an x86_64 darwin toolchain in @local_cc_config
for some reason I was under the impression that Bazel was running under Rosetta in which case there would be, I think
does the error go away if you don't specify --config=x86?

oh whoops; does it get any further if you add --keep_going?

does the error go away if you don't specify --config=x86?

I get the same output for all combinations of --keep_going and --config={x86,arm}
INFO: Build option --platforms has changed, discarding analysis cache.
ERROR: /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/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'
WARNING: errors encountered while analyzing target '//:test': it will not be built
INFO: Analyzed target //:test (1 packages loaded, 4140 targets configured).
INFO: Found 0 targets...
INFO: Empty query results
digraph mygraph {
  node [shape=box];
}
ERROR: command succeeded, but not all targets were analyzed
INFO: Elapsed time: 16.547s
INFO: 0 processes.
FAILED: Build did NOT complete successfully

is the output when --keep_going is present

😕
how about with --cpu=darwin_arm64?

Looks like that works?
~/stripe/sandbox/rrbutani-workspace
❯ bazel build //:test --cpu=darwin_arm64 --config=arm64
INFO: Build option --cpu has changed, discarding analysis cache.
INFO: Analyzed target //:test (0 packages loaded, 4144 targets configured).
INFO: Found 1 target...
INFO: From Linking test:
ld64.lld: warning: ignoring unknown argument: -headerpad_max_install_names
ld64.lld: warning: -sdk_version is required when emitting min version load command.  Setting sdk version to match provided min version
Target //:test up-to-date:
  bazel-bin/test
INFO: Elapsed time: 15.586s, Critical Path: 11.68s
INFO: 5 processes: 3 internal, 2 darwin-sandbox.
INFO: Build completed successfully, 5 total actions

~/stripe/sandbox/rrbutani-workspace   15s
❯ file bazel-bin/test
bazel-bin/test: Mach-O 64-bit executable arm64

oh neat
that's super weird though; I thought ^ wouldn't be necessary anymore 😕
Does just --host_cpu=darwin_arm64 also work?

Neither of those works
~/stripe/sandbox/rrbutani-workspace
❯ bazel build //:test --host_cpu=darwin_arm64
INFO: Build options --cpu, --host_cpu, and --platforms have changed, discarding analysis cache.
ERROR: /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/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'
ERROR: Analysis of target '//:test' failed; build aborted: Analysis of target '@local_config_cc//:toolchain' failed
INFO: Elapsed time: 1.699s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 60 targets configured)

~/stripe/sandbox/rrbutani-workspace
❯ bazel build //:test --host_cpu=darwin_arm64 --config=arm64
INFO: Build option --platforms has changed, discarding analysis cache.
ERROR: /private/var/tmp/_bazel/e9cb4153e0861999826e8879b02ae2cc/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'
ERROR: Analysis of target '//:test' failed; build aborted: Analysis of target '@local_config_cc//:toolchain' failed
INFO: Elapsed time: 1.270s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 4133 targets configured)

You might also be curious to see the cquery output with --cpu=darwin_arm64

Click to expand
❯ bazel cquery 'deps(//:test)' --output=graph --config=arm64 --keep_going --cpu=darwin_arm64
INFO: Build options --cpu and --host_cpu have changed, discarding analysis cache.
INFO: Analyzed target //:test (0 packages loaded, 4144 targets configured).
INFO: Found 1 target...
digraph mygraph {
  node [shape=box];
  "//:test (f7c5632)"
  "//:test (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "//:test (f7c5632)" -> "//:clang-darwin-arm64-toolchain (HOST)"
  "//:test (f7c5632)" -> "//:test.cc (null)"
  "//:test (f7c5632)" -> "@bazel_tools//tools/cpp:grep-includes (HOST)"
  "//:test (f7c5632)" -> "@bazel_tools//tools/cpp:malloc (f7c5632)"
  "//:test (f7c5632)" -> "@bazel_tools//tools/cpp:toolchain (f7c5632)"
  "//:test (f7c5632)" -> "@bazel_tools//tools/cpp:toolchain_type (f7c5632)"
  "//:test (f7c5632)" -> "@bazel_tools//tools/def_parser:def_parser (HOST)"
  "//:test (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@bazel_tools//tools/def_parser:def_parser (HOST)"
  "@bazel_tools//tools/def_parser:def_parser (HOST)" -> "@bazel_tools//src/conditions:host_windows (HOST)"
  "@bazel_tools//tools/def_parser:def_parser (HOST)" -> "@bazel_tools//tools/def_parser:no_op.bat (null)"
  "@bazel_tools//tools/def_parser:def_parser (HOST)" -> "@local_config_platform//:host (HOST)"
  "@bazel_tools//tools/def_parser:no_op.bat (null)"
  "@bazel_tools//src/conditions:host_windows (HOST)"
  "@bazel_tools//src/conditions:host_windows (HOST)" -> "@local_config_platform//:host (HOST)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)" -> "//:clang-darwin-arm64-toolchain (HOST)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)" -> "@bazel_tools//tools/cpp:grep-includes (HOST)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)" -> "@bazel_tools//tools/cpp:toolchain (f7c5632)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)" -> "@bazel_tools//tools/cpp:toolchain_type (f7c5632)"
  "@bazel_tools//tools/cpp:malloc (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@bazel_tools//tools/cpp:toolchain_type (f7c5632)"
  "@bazel_tools//tools/cpp:toolchain (f7c5632)"
  "@bazel_tools//tools/cpp:toolchain (f7c5632)" -> "@local_config_cc//:toolchain (f7c5632)"
  "@local_config_cc//:toolchain (f7c5632)"
  "@local_config_cc//:toolchain (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "@local_config_cc//:toolchain (f7c5632)" -> "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)"
  "@local_config_cc//:toolchain (f7c5632)" -> "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)"
  "@local_config_cc//:toolchain (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@bazel_tools//tools/build_defs/cc/whitelists/parse_headers_and_layering_check:disabling_parse_headers_and_layering_check_allowed (null)\n@bazel_tools//tools/build_defs/cc/whitelists/starlark_hdrs_check:loose_header_check_allowed_in_toolchain (null)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@bazel_tools//tools/cpp:interface_library_builder (49db493)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@bazel_tools//tools/cpp:link_dynamic_library (49db493)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@local_config_cc//:compiler_deps (49db493)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@local_config_cc//:empty (49db493)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@local_config_cc//:local (f7c5632)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@local_config_cc//:module.modulemap (null)"
  "@local_config_cc//:cc-compiler-darwin_arm64 (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@local_config_cc//:module.modulemap (null)"
  "@local_config_cc//:local (f7c5632)"
  "@local_config_cc//:local (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "@local_config_cc//:local (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@local_config_cc//:compiler_deps (49db493)"
  "@local_config_cc//:compiler_deps (49db493)" -> "@local_config_cc//:builtin_include_directory_paths (null)"
  "@local_config_cc//:compiler_deps (49db493)" -> "@local_config_cc//:cc_wrapper (49db493)"
  "@local_config_cc//:compiler_deps (49db493)" -> "@local_config_platform//:host (49db493)"
  "@local_config_cc//:cc_wrapper (49db493)"
  "@local_config_cc//:cc_wrapper (49db493)" -> "@local_config_cc//:cc_wrapper.sh (null)"
  "@local_config_cc//:cc_wrapper (49db493)" -> "@local_config_platform//:host (49db493)"
  "@local_config_cc//:cc_wrapper.sh (null)"
  "@local_config_cc//:builtin_include_directory_paths (null)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "@bazel_tools//tools/build_defs/cc/whitelists/parse_headers_and_layering_check:disabling_parse_headers_and_layering_check_allowed (null)\n@bazel_tools//tools/build_defs/cc/whitelists/starlark_hdrs_check:loose_header_check_allowed_in_toolchain (null)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "@bazel_tools//tools/cpp:interface_library_builder (49db493)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "@bazel_tools//tools/cpp:link_dynamic_library (49db493)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "@local_config_cc//:empty (49db493)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "@local_config_cc//:stub_armeabi-v7a (f7c5632)"
  "@local_config_cc//:cc-compiler-armeabi-v7a (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@local_config_cc//:stub_armeabi-v7a (f7c5632)"
  "@local_config_cc//:stub_armeabi-v7a (f7c5632)" -> "//:apple-silicon (f7c5632)"
  "@local_config_cc//:stub_armeabi-v7a (f7c5632)" -> "@local_config_platform//:host (f7c5632)"
  "@local_config_platform//:host (f7c5632)"
  "@local_config_platform//:host (f7c5632)" -> "@platforms//cpu:x86_64 (f7c5632)"
  "@local_config_platform//:host (f7c5632)" -> "@platforms//os:osx (f7c5632)"
  "@platforms//cpu:x86_64 (f7c5632)"
  "@platforms//cpu:x86_64 (f7c5632)" -> "@platforms//cpu:cpu (f7c5632)"
  "@local_config_cc//:empty (49db493)"
  "@local_config_cc//:empty (49db493)" -> "@local_config_platform//:host (49db493)"
  "@bazel_tools//tools/cpp:link_dynamic_library (49db493)"
  "@bazel_tools//tools/cpp:link_dynamic_library (49db493)" -> "@bazel_tools//tools/cpp:link_dynamic_library.sh (null)"
  "@bazel_tools//tools/cpp:link_dynamic_library (49db493)" -> "@local_config_platform//:host (49db493)"
  "@bazel_tools//tools/cpp:interface_library_builder (49db493)"
  "@bazel_tools//tools/cpp:interface_library_builder (49db493)" -> "@bazel_tools//tools/cpp:build_interface_so (null)"
  "@bazel_tools//tools/cpp:interface_library_builder (49db493)" -> "@local_config_platform//:host (49db493)"
  "@local_config_platform//:host (49db493)"
  "@local_config_platform//:host (49db493)" -> "@platforms//cpu:x86_64 (49db493)"
  "@local_config_platform//:host (49db493)" -> "@platforms//os:osx (49db493)"
  "@platforms//os:osx (49db493)"
  "@platforms//os:osx (49db493)" -> "@platforms//os:os (49db493)"
  "@platforms//os:os (49db493)"
  "@platforms//cpu:x86_64 (49db493)"
  "@platforms//cpu:x86_64 (49db493)" -> "@platforms//cpu:cpu (49db493)"
  "@platforms//cpu:cpu (49db493)"
  "@bazel_tools//tools/cpp:grep-includes (HOST)"
  "@bazel_tools//tools/cpp:grep-includes (HOST)" -> "@bazel_tools//tools/cpp:grep-includes.sh (null)"
  "@bazel_tools//tools/cpp:grep-includes (HOST)" -> "@local_config_platform//:host (HOST)"
  "@bazel_tools//tools/cpp:grep-includes.sh (null)"
  "//:test.cc (null)"
  "//:clang-darwin-arm64-toolchain (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "//:clang-darwin-arm64-config (HOST)\n@llvm_toolchain//:empty (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "//:clang-darwin-arm64-toolchain-all-files (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "//:clang-darwin-arm64-toolchain-archiver-files (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "//:clang-darwin-arm64-toolchain-assembler-files (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "//:clang-darwin-arm64-toolchain-compiler-files (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "//:clang-darwin-arm64-toolchain-linker-files (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "@bazel_tools//tools/build_defs/cc/whitelists/parse_headers_and_layering_check:disabling_parse_headers_and_layering_check_allowed (null)\n@bazel_tools//tools/build_defs/cc/whitelists/starlark_hdrs_check:loose_header_check_allowed_in_toolchain (null)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "@bazel_tools//tools/cpp:interface_library_builder (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "@bazel_tools//tools/cpp:link_dynamic_library (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "@llvm_toolchain//:objcopy (HOST)"
  "//:clang-darwin-arm64-toolchain (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:objcopy (HOST)"
  "@llvm_toolchain//:objcopy (HOST)" -> "@llvm_toolchain//:bin/llvm-objcopy (null)"
  "@llvm_toolchain//:objcopy (HOST)" -> "@local_config_platform//:host (HOST)"
  "@bazel_tools//tools/cpp:link_dynamic_library (HOST)"
  "@bazel_tools//tools/cpp:link_dynamic_library (HOST)" -> "@bazel_tools//tools/cpp:link_dynamic_library.sh (null)"
  "@bazel_tools//tools/cpp:link_dynamic_library (HOST)" -> "@local_config_platform//:host (HOST)"
  "@bazel_tools//tools/cpp:link_dynamic_library.sh (null)"
  "@bazel_tools//tools/cpp:interface_library_builder (HOST)"
  "@bazel_tools//tools/cpp:interface_library_builder (HOST)" -> "@bazel_tools//tools/cpp:build_interface_so (null)"
  "@bazel_tools//tools/cpp:interface_library_builder (HOST)" -> "@local_config_platform//:host (HOST)"
  "@bazel_tools//tools/cpp:build_interface_so (null)"
  "@bazel_tools//tools/build_defs/cc/whitelists/parse_headers_and_layering_check:disabling_parse_headers_and_layering_check_allowed (null)\n@bazel_tools//tools/build_defs/cc/whitelists/starlark_hdrs_check:loose_header_check_allowed_in_toolchain (null)"
  "//:clang-darwin-arm64-toolchain-linker-files (HOST)"
  "//:clang-darwin-arm64-toolchain-linker-files (HOST)" -> "//:clang-darwin-arm64-toolchain-linker_components (HOST)"
  "//:clang-darwin-arm64-toolchain-linker-files (HOST)" -> "@llvm_toolchain//:cc_wrapper (HOST)"
  "//:clang-darwin-arm64-toolchain-linker-files (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler-files (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler-files (HOST)" -> "//:clang-darwin-arm64-toolchain-compiler_components (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler-files (HOST)" -> "@llvm_toolchain//:cc_wrapper (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler-files (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-assembler-files (HOST)"
  "//:clang-darwin-arm64-toolchain-assembler-files (HOST)" -> "@llvm_toolchain//:as (HOST)"
  "//:clang-darwin-arm64-toolchain-assembler-files (HOST)" -> "@llvm_toolchain//:cc_wrapper (HOST)"
  "//:clang-darwin-arm64-toolchain-assembler-files (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:as (HOST)"
  "@llvm_toolchain//:as (HOST)" -> "@llvm_toolchain//:bin/clang (null)"
  "@llvm_toolchain//:as (HOST)" -> "@llvm_toolchain//:bin/llvm-as (null)"
  "@llvm_toolchain//:as (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-archiver-files (HOST)"
  "//:clang-darwin-arm64-toolchain-archiver-files (HOST)" -> "@llvm_toolchain//:ar (HOST)"
  "//:clang-darwin-arm64-toolchain-archiver-files (HOST)" -> "@llvm_toolchain//:cc_wrapper (HOST)"
  "//:clang-darwin-arm64-toolchain-archiver-files (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-all-files (HOST)"
  "//:clang-darwin-arm64-toolchain-all-files (HOST)" -> "//:clang-darwin-arm64-toolchain-all_components (HOST)"
  "//:clang-darwin-arm64-toolchain-all-files (HOST)" -> "@llvm_toolchain//:cc_wrapper (HOST)"
  "//:clang-darwin-arm64-toolchain-all-files (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:cc_wrapper (HOST)"
  "@llvm_toolchain//:cc_wrapper (HOST)" -> "@llvm_toolchain//:bin/cc_wrapper.sh (null)"
  "@llvm_toolchain//:cc_wrapper (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-all_components (HOST)"
  "//:clang-darwin-arm64-toolchain-all_components (HOST)" -> "//:clang-darwin-arm64-toolchain-compiler_components (HOST)"
  "//:clang-darwin-arm64-toolchain-all_components (HOST)" -> "//:clang-darwin-arm64-toolchain-linker_components (HOST)"
  "//:clang-darwin-arm64-toolchain-all_components (HOST)" -> "@llvm_toolchain//:binutils_components (HOST)"
  "//:clang-darwin-arm64-toolchain-all_components (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:binutils_components (HOST)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/ar (null)\n@llvm_toolchain//:bin/bugpoint (null)\n@llvm_toolchain//:bin/c-index-test (null)\n@llvm_toolchain//:bin/clang-12 (null)\n@llvm_toolchain//:bin/clang-apply-replacements (null)\n@llvm_toolchain//:bin/clang-change-namespace (null)\n@llvm_toolchain//:bin/clang-check (null)\n@llvm_toolchain//:bin/clang-cl (null)\n@llvm_toolchain//:bin/clang-doc (null)\n@llvm_toolchain//:bin/clang-extdef-mapping (null)\n@llvm_toolchain//:bin/clang-format (null)\n...and 96 more items"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/cc_wrapper.sh (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/clang (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/clang++ (null)\n@llvm_toolchain//:bin/clang-cpp (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/ld (null)\n@llvm_toolchain//:bin/ld.gold (null)\n@llvm_toolchain//:bin/ld.lld (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/llvm-ar (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/llvm-as (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@llvm_toolchain//:bin/llvm-objcopy (null)"
  "@llvm_toolchain//:binutils_components (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:bin/llvm-objcopy (null)"
  "@llvm_toolchain//:bin/llvm-as (null)"
  "@llvm_toolchain//:bin/cc_wrapper.sh (null)"
  "@llvm_toolchain//:bin/ar (null)\n@llvm_toolchain//:bin/bugpoint (null)\n@llvm_toolchain//:bin/c-index-test (null)\n@llvm_toolchain//:bin/clang-12 (null)\n@llvm_toolchain//:bin/clang-apply-replacements (null)\n@llvm_toolchain//:bin/clang-change-namespace (null)\n@llvm_toolchain//:bin/clang-check (null)\n@llvm_toolchain//:bin/clang-cl (null)\n@llvm_toolchain//:bin/clang-doc (null)\n@llvm_toolchain//:bin/clang-extdef-mapping (null)\n@llvm_toolchain//:bin/clang-format (null)\n...and 96 more items"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)" -> "@llvm_toolchain//:ar (HOST)"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)" -> "@llvm_toolchain//:clang (HOST)"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)" -> "@llvm_toolchain//:ld (HOST)"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)" -> "@llvm_toolchain//:lib (HOST)"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-linker_components (HOST)" -> "@macos-11.3-sdk//:sysroot (HOST)"
  "@llvm_toolchain//:lib (HOST)"
  "@llvm_toolchain//:lib (HOST)" -> "@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.cc_kext.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.cc_kext_ios.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.fuzzer_interceptors_ios.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.fuzzer_interceptors_iossim.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.fuzzer_interceptors_osx.a (null)\n...and 171 more items"
  "@llvm_toolchain//:lib (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.cc_kext.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.cc_kext_ios.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.fuzzer_interceptors_ios.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.fuzzer_interceptors_iossim.a (null)\n@llvm_toolchain//:lib/clang/12.0.0/lib/darwin/libclang_rt.fuzzer_interceptors_osx.a (null)\n...and 171 more items"
  "@llvm_toolchain//:ld (HOST)"
  "@llvm_toolchain//:ld (HOST)" -> "@llvm_toolchain//:bin/ld (null)\n@llvm_toolchain//:bin/ld.gold (null)\n@llvm_toolchain//:bin/ld.lld (null)"
  "@llvm_toolchain//:ld (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:bin/ld (null)\n@llvm_toolchain//:bin/ld.gold (null)\n@llvm_toolchain//:bin/ld.lld (null)"
  "@llvm_toolchain//:ar (HOST)"
  "@llvm_toolchain//:ar (HOST)" -> "@llvm_toolchain//:bin/llvm-ar (null)"
  "@llvm_toolchain//:ar (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:bin/llvm-ar (null)"
  "//:clang-darwin-arm64-toolchain-compiler_components (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler_components (HOST)" -> "@llvm_toolchain//:clang (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler_components (HOST)" -> "@llvm_toolchain//:include (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler_components (HOST)" -> "@local_config_platform//:host (HOST)"
  "//:clang-darwin-arm64-toolchain-compiler_components (HOST)" -> "@macos-11.3-sdk//:sysroot (HOST)"
  "@macos-11.3-sdk//:sysroot (HOST)"
  "@macos-11.3-sdk//:sysroot (HOST)" -> "@local_config_platform//:host (HOST)"
  "@macos-11.3-sdk//:sysroot (HOST)" -> "@macos-11.3-sdk//:usr/bin/cups-config (null)\n@macos-11.3-sdk//:usr/bin/curl-config (null)\n@macos-11.3-sdk//:usr/bin/krb5-config (null)\n@macos-11.3-sdk//:usr/bin/ncurses5.4-config (null)\n@macos-11.3-sdk//:usr/bin/net-snmp-config (null)\n@macos-11.3-sdk//:usr/bin/pcap-config (null)\n@macos-11.3-sdk//:usr/bin/php-config (null)\n@macos-11.3-sdk//:usr/bin/xml2-config (null)\n@macos-11.3-sdk//:usr/bin/xslt-config (null)\n...and 3388 more items"
  "@macos-11.3-sdk//:usr/bin/cups-config (null)\n@macos-11.3-sdk//:usr/bin/curl-config (null)\n@macos-11.3-sdk//:usr/bin/krb5-config (null)\n@macos-11.3-sdk//:usr/bin/ncurses5.4-config (null)\n@macos-11.3-sdk//:usr/bin/net-snmp-config (null)\n@macos-11.3-sdk//:usr/bin/pcap-config (null)\n@macos-11.3-sdk//:usr/bin/php-config (null)\n@macos-11.3-sdk//:usr/bin/xml2-config (null)\n@macos-11.3-sdk//:usr/bin/xslt-config (null)\n...and 3388 more items"
  "@llvm_toolchain//:include (HOST)"
  "@llvm_toolchain//:include (HOST)" -> "@llvm_toolchain//:include/c++/v1/__availability (null)\n@llvm_toolchain//:include/c++/v1/__bit_reference (null)\n@llvm_toolchain//:include/c++/v1/__bits (null)\n@llvm_toolchain//:include/c++/v1/__bsd_locale_defaults.h (null)\n@llvm_toolchain//:include/c++/v1/__bsd_locale_fallbacks.h (null)\n@llvm_toolchain//:include/c++/v1/__config (null)\n@llvm_toolchain//:include/c++/v1/__cxxabi_config.h (null)\n@llvm_toolchain//:include/c++/v1/__debug (null)\n...and 363 more items"
  "@llvm_toolchain//:include (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:include/c++/v1/__availability (null)\n@llvm_toolchain//:include/c++/v1/__bit_reference (null)\n@llvm_toolchain//:include/c++/v1/__bits (null)\n@llvm_toolchain//:include/c++/v1/__bsd_locale_defaults.h (null)\n@llvm_toolchain//:include/c++/v1/__bsd_locale_fallbacks.h (null)\n@llvm_toolchain//:include/c++/v1/__config (null)\n@llvm_toolchain//:include/c++/v1/__cxxabi_config.h (null)\n@llvm_toolchain//:include/c++/v1/__debug (null)\n...and 363 more items"
  "@llvm_toolchain//:clang (HOST)"
  "@llvm_toolchain//:clang (HOST)" -> "@llvm_toolchain//:bin/clang (null)"
  "@llvm_toolchain//:clang (HOST)" -> "@llvm_toolchain//:bin/clang++ (null)\n@llvm_toolchain//:bin/clang-cpp (null)"
  "@llvm_toolchain//:clang (HOST)" -> "@local_config_platform//:host (HOST)"
  "@llvm_toolchain//:bin/clang++ (null)\n@llvm_toolchain//:bin/clang-cpp (null)"
  "@llvm_toolchain//:bin/clang (null)"
  "//:clang-darwin-arm64-config (HOST)\n@llvm_toolchain//:empty (HOST)"
  "//:clang-darwin-arm64-config (HOST)\n@llvm_toolchain//:empty (HOST)" -> "@local_config_platform//:host (HOST)"
  "@local_config_platform//:host (HOST)"
  "@local_config_platform//:host (HOST)" -> "@platforms//cpu:x86_64 (HOST)"
  "@local_config_platform//:host (HOST)" -> "@platforms//os:osx (HOST)"
  "@platforms//os:osx (HOST)"
  "@platforms//os:osx (HOST)" -> "@platforms//os:os (HOST)"
  "@platforms//os:os (HOST)"
  "@platforms//cpu:x86_64 (HOST)"
  "@platforms//cpu:x86_64 (HOST)" -> "@platforms//cpu:cpu (HOST)"
  "@platforms//cpu:cpu (HOST)"
  "//:apple-silicon (f7c5632)"
  "//:apple-silicon (f7c5632)" -> "@platforms//cpu:arm64 (f7c5632)"
  "//:apple-silicon (f7c5632)" -> "@platforms//os:osx (f7c5632)"
  "@platforms//os:osx (f7c5632)"
  "@platforms//os:osx (f7c5632)" -> "@platforms//os:os (f7c5632)"
  "@platforms//os:os (f7c5632)"
  "@platforms//cpu:arm64 (f7c5632)"
  "@platforms//cpu:arm64 (f7c5632)" -> "@platforms//cpu:cpu (f7c5632)"
  "@platforms//cpu:cpu (f7c5632)"
}
INFO: Elapsed time: 1.749s
INFO: 0 processes.
INFO: Build completed successfully, 0 total actions

thanks, I was just about to ask 😛

that's super weird; maybe something leftover from the _toolchain/CROSSTOOL era makes cc_binarys have an implicit dep on @local_config_cc//:toolchain or something
regardless – I'm glad it works! even though it really does seem like you shouldn't have to pass in --cpu=darwin_arm64
Just to be sure: does actually running the binary that's produced work?

oh wait
I think your script hardcodes x86_64 for the installer it grabs IIUC? Do you know if Bazel is actually getting run through Rosetta?
I think that'd explain the --cpu stuff, maybe

I think your script hardcodes x86_64 for the installer it grabs IIUC. Do you know if Bazel is actually getting run through Rosetta?

Interesting, i'll take a look.

Just to be sure: does actually running the binary that's produced work?

uhh...
~/stripe/sandbox/rrbutani-workspace
❯ bazel build //:test --cpu=darwin_arm64 --config=arm64
INFO: Build options --cpu and --host_cpu have changed, discarding analysis cache.
INFO: Analyzed target //:test (0 packages loaded, 4144 targets configured).
INFO: Found 1 target...
Target //:test up-to-date:
  bazel-bin/test
INFO: Elapsed time: 1.107s, Critical Path: 0.04s
INFO: 1 process: 1 internal.
INFO: Build completed successfully, 1 total action

~/stripe/sandbox/rrbutani-workspace
❯ ls -lh bazel-bin/test
-r-xr-xr-x 1 jez wheel 39K Sep  2 22:32 bazel-bin/test

~/stripe/sandbox/rrbutani-workspace
❯ file bazel-bin/test
bazel-bin/test: Mach-O 64-bit executable arm64

~/stripe/sandbox/rrbutani-workspace
❯ bazel-bin/test
[1]    30775 killed     bazel-bin/test

~/stripe/sandbox/rrbutani-workspace
❯ lldb -- bazel-bin/test
(lldb) target create "bazel-bin/test"
Current executable set to '/Users/jez/stripe/sandbox/rrbutani-workspace/bazel-bin/test' (arm64).
(lldb) r
error: process exited with status -1 (no such process.)
(lldb) ^D

~/stripe/sandbox/rrbutani-workspace   14s
❯ sudo dtruss -- bazel-bin/test
Password:
dtrace: system integrity protection is on, some features will not be available

dtrace: failed to execute bazel-bin/test: (os/kern) failure

oh no

maybe it's the dylibs? usually that prints a real error though
what does otool -L bazel-bin/test say?

I think your script hardcodes x86_64 for the installer it grabs IIUC. Do you know if Bazel is actually getting run through Rosetta?

Good catch. When I fix the script to use uname -p to detect the host processor, it downloads an arm64 version of bazel and then i can build C++ targets without needing the --cpu flag, and the targets actually run:
❯ ./bazel build //:test --config=arm64
Starting local Bazel server and connecting to it...
INFO: Analyzed target //:test (16 packages loaded, 70 targets configured).
INFO: Found 1 target...
Target //:test up-to-date:
  bazel-bin/test
INFO: Elapsed time: 2.691s, Critical Path: 0.34s
INFO: 8 processes: 6 internal, 2 darwin-sandbox.
INFO: Build completed successfully, 8 total actions

~/stripe/sandbox/rrbutani-workspace
❯ bazel-bin/test
yo!

I tried this before I got a chance to run otool on the old executable. I'll probably skip that, because we should be using arm64 bazel releases anyways.

👌
It's definitely strange that the executable produced with x86_64 bazel didn't work (it should be the exact same as the executable you have now, I'm pretty sure – the toolchain is the same either way) but it'll take it.
Thanks for testing!

Yep, thanks for helping debug!
For what it's worth, I also tried replacing the http_archive with this:
new_local_repository(
    name = "macos-11.3-sdk",
    path = "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk",
    build_file_content = """
filegroup(
  name = "sysroot",
  srcs = glob(["usr/**"], exclude = ["usr/share/**"]),
  visibility = ["//visibility:public"],
)
""",
)

and it also builds and runs successfully (figured I'd mention it at least for posterity's sake, even if you don't end up incorporating it in a change).
Though (not sure how this stuff works) maybe that's the sort of thing that wouldn't even be required to declare explicitly if you were ok with an SDK being too old.
Probably tomorrow or this weekend I'll see if I can take the mini-workspace you made and incorporate it into the build system for https://github.com/sorbet/sorbet. It's not the craziest C++ codebase, but it'll be a little more of a stress test than a hello world program.
Anyways, thanks again!

Also for posterity's sake: the final contents of the workspace that we got working in the end:
rrbutani-workspace.zip
and the full build command:
bazel build //:test --config=arm64

For what it's worth, I also tried replacing the http_archive with this:
new_local_repository(
    name = "macos-11.3-sdk",
    path = "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk",
    build_file_content = """
filegroup(
  name = "sysroot",
  srcs = glob(["usr/**"], exclude = ["usr/share/**"]),
  visibility = ["//visibility:public"],
)
""",
)

and it also builds and runs successfully (figured I'd mention it at least for posterity's sake, even if you don't end up incorporating it in a change).

Thanks; good to know that works as expected.

Though (not sure how this stuff works) maybe that's the sort of thing that wouldn't even be required to declare explicitly if you were ok with an SDK being too old.

For host toolchains this logic picks up the SDK and refers to it by absolute path in the generated toolchains.
For extra_targets toolchains I think it makes sense to fetch the sysroot, like we do for WASI. That way if someone tries to, for example, specify aarch64-apple-darwin as an extra target on a Linux host machine, they won't need to go find and fetch an SDK themselves.

Probably tomorrow or this weekend I'll see if I can take the mini-workspace you made and incorporate it into the build system for https://github.com/sorbet/sorbet. It's not the craziest C++ codebase, but it'll be a little more of a stress test than a hello world program.

Thanks! Looking forward to seeing what else I broke 😛

@jez do you have the commit that made it work in sorbet?

I haven’t done any further work on this

I've been working on compiling the Sorbet project using the provided ARM64 toolchains. It seems that the playground workspace changes work as intended, but there is one thing missing for me to be able to fully verify the build completes and works.
The only change I had to make to the playground code was setting custom_target_triple = "arm64-apple-macosx12.1.0" in the cc_toolchain_config. If I don't do that, we end up having the triple as iOS for some reason (which doesn't happen in the playground, but does happen in Sorbet).
Also, despite being on the most recent macos, I still have to use -mlinker-version=450 or else linking fails because the flag platform_version is not recognized.
The last remaining error is when linking we get the error unable to find framework Foundation. This framework is used by one of Sorbet's dependencies (abseil). I tried a few things to fix this, but have been unable so far. Here is what I tried:

Adding the framework paths using -F/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks does not work (the search paths are correct, but linking still can't find it)
Same thing for -F/System/Library/Frameworks
Tried compiling with the -framework Foundation flag using LLVM 12 and 13 outside of bazel-toolchain. My understanding based on the release notes for LLD 13 was that support for ARM64 was added in that version. However, I was able to compile using the framework flag using LLVM standalone both version 12 and 13. I can't test LLVM 13 with the playground changes though, because that version doesn't support LLVM 13

Would it be possible to rebase that playground version with the current LLVM 13 support that is already in main? Do you believe that is likely the cause of frameworks not working or could it be something else that I am missing?
Note: another thing worth noting is that, even when using the playground, we must sign the resulting binary with codesign or else M1 machines will not execute it. I noticed I don't have to do that when using LLVM standalone, so I wonder if this is within the scope of bazel-toolchain or not (or if LLVM 13 fixes it).

@vinistock which playground workspace are you referring to? Do you have a fork/branch that you could share?

The only change I had to make to the playground code was setting custom_target_triple = "arm64-apple-macosx12.1.0" in the cc_toolchain_config. If I don't do that, we end up having the triple as iOS for some reason (which doesn't happen in the playground, but does happen in Sorbet).

Hmm. Are there maybe other toolchains registered by the Sorbet workspace? Can you verify that the aarch64-apple-darwin actually gets used (--toolchain_resolution_debug)? The constraints are generated from the target triple so it's definitely possible something shifted/is broken and is causing arm64-apple-* to generate constraints that result in the toolchain being used but not aarch64-apple-darwin (iirc arm64 and aarch64 are the same CPU constraint though). I'll have to look into it more, later.

Also, despite being on the most recent macos, I still have to use -mlinker-version=450 or else linking fails because the flag platform_version is not recognized.

This is odd; lld has definitely had support for -platform_version for several releases. 😕

The last remaining error is when linking we get the error unable to find framework Foundation. This framework is used by one of Sorbet's dependencies (abseil). I tried a few things to fix this, but have been unable so far. Here is what I tried:
* Adding the framework paths using `-F/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks` does not work (the search paths are correct, but linking still can't find it)

* Same thing for `-F/System/Library/Frameworks`

* Tried compiling with the `-framework Foundation` flag using LLVM 12 and 13 standalone outside of `bazel-toolchain`. My understanding based on the [release notes for LLD 13](https://releases.llvm.org/13.0.0/tools/lld/docs/ReleaseNotes.html#id9) was that support for ARM64 was added in that version. However, I was able to compile using the framework flag using LLVM standalone both version 12 and 13. I can't test LLVM 13 with the playground changes though, because that version doesn't support LLVM 13

Not sure what's going on here; bazel-toolchain should add that path to the search directories anyways (through the sysroot which is set to be /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk in the playground workspace).
Maybe this has finally become an issue? It'd be helpful to compare against Sorbet on regular x86_64 macOS with the same toolchain (if that builds successfully).

Would it be possible to rebase that playground version with the current LLVM 13 support that is already in main?

The playground is based on #85; main has grown some significant changes in the meantime that make rebasing that PR not entirely trivial.

Do you believe that is likely the cause of frameworks not working or could it be something else that I am missing?

I'm not really sure what's going on but I don't think it's an LLVM version issue.

I did try to use the current version in main to try to upgrade to LLVM 13, but doing so fails with this error, so maybe we need something else too.
Error in fail: Unknown LLVM release: clang+llvm-13.0.0-arm64-apple-darwin.tar.xz

The version of this repo currently in main is trying to grab arm64 binaries for LLVM on macOS for which there aren't official LLVM releases. The playground workspace just uses the x86_64 macOS LLVM binaries through Rosetta IIRC. (main also doesn't have the custom toolchain stuff #85 has).

Note: another thing worth noting is that, even when using the playground, we must sign the resulting binary with codesign or else M1 machines will not execute it. I noticed I don't have to do that when using LLVM standalone, so I wonder if this is within the scope of bazel-toolchain or not (or if LLVM 13 fixes it).

My understanding is that lld does sign the binaries it produces but that this only landed in LLVM 13.
@jez do you remember if you needed to explicitly sign the binaries you got out of Bazel?
Regardless, I think this is very much in scope for bazel-toolchain.

@vinistock Thanks for the notes! I now have access to an Apple Silicon machine; I'm hoping to get back to working on this issue early next week.
If possible, can you post your modified workspace/the commands you are running?

@rrbutani thank you so much for the detailed and quick response. I really appreciate your assistance.
Debugging the toolchains
I'm not exactly sure how I should be reading this output. Please, let me know if you need more information. But running build using the --toolchain_resolution_debug flag, prints these statements related to the ARM64 toolchain (plus other information related to other things).
It seems to reject the toolchain, but then selects it afterwards. Not sure if there's an issue in toolchain resolution here.
INFO: ToolchainResolution:   Type @bazel_tools//tools/cpp:toolchain_type: target platform //:apple-silicon: execution @local_config_platform//:host: Selected toolchain //:clang-darwin-arm64-toolchain

...

INFO: ToolchainResolution: Target platform //:apple-silicon: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/cpp:toolchain_type -> toolchain //:clang-darwin-arm64-toolchain

...

INFO: ToolchainResolution: Target platform @local_config_platform//:host: Selected execution platform @local_config_platform//:host, type @bazel_tools//tools/cpp:toolchain_type -> toolchain @llvm_toolchain_12_0_0//:cc-clang-darwin

Comparing with x86
With the same style of configuration of the playground, if I use --platforms=@//:apple-x86 I can compile Sorbet and do not have the error related to the Foundation framework. So, for some reason, this indeed seems like an ARM64 related issue.
Playground example
The playground example I meant is rrbutani-workspace. I actually forgot to upload, but I modified that workspace to reproduce the framework issue. It's the same workspace, but I changed the triple and added a linkopt for -framework Foundation, which is exactly what abseil does. It will probably be easier to debug this in the playground, since it has a much simpler configuration.
In this playground repo, if the link option for framework is present I cannot compile with the error unable to find framework Foundation (despite the search paths being correct).
If I remove the -framework Foundation flag, I can compile, but cannot run the executable without force signing it with codesign.
Notice that in this playground repo, I can also compile the x86 version successfully even with the framework flag (exactly as in Sorbet).
The command I'm using to compile is
# Successfully compiles even with the -framework Foundation linkopt
bazel build //:test --config=x86

# Fails with `unable to find framework Foundation`
bazel build //:test --config=arm64

plaground-framework.zip

Since we determined that we'll need LLVM 13 for signing binaries, I have begun looking into what we'll need to upgrade Sorbet to LLVM 13, using the latest version of bazel-toolchain.
The upgrade is relatively smooth, but I bumped into another issue that I'm having trouble figuring out. Please, let me know if this is not within the scope of bazel-toolchain.
What the upgrade consisted of
Basically, there were two steps

upgrading the LLVM version to 13.0.0
changing the crosstool_top option to be incompatible_enable_cc_toolchain_resolution as instructed in the README

The bug
After the upgrade, I was able to determine that this invocation to find_cpp_toolchain started returning the wrong toolchain.
In version 12, the toolchain object we get has all the LLVM paths in it (includes, cc_wrapper and so on), all pointing to (bazel info output_base)/external/llvm_toolchain/....
With version 13, the latest bazel-toolchain and the incompatible_enable_cc_toolchain_resolution flag, the same call returns a different toolchain, where the compiler path is different and points to external/local_config_cc/wrapped_clang.  The object includes none of the LLVM paths.
In addition to returning the wrong toolchain, I also noticed that all paths are now relative, whereas when using version 12 they are all absolute.
Attempts to fix it
In the Bazel issue linked in the README describing the migration for incompatible_enable_cc_toolchain_resolution, they mention that find_cpp_toolchain has been deprecated and that we should instead use find_cc_toolchain.
I tried doing the migration, making sure that the rules depended on the right toolchains and that we were now using the new rules_cc dependency. Unfortunately, this did not fix the problem and the new find_cc_toolchain still returns the same incorrect response.
I believe this might be related to the incompatible_enable_cc_toolchain_resolution flag and not LLVM 13 itself.
Any ideas on why the LLVM toolchain is not being returned by find_cc_toolchain? Also, please let me know if I can provide more information to be more helpful in the investigations.

Please, let me know if this is not within the scope of bazel-toolchain.

This is a little out of scope for this project but that's fine.

After the upgrade, I was able to determine that this invocation to find_cpp_toolchain started returning the wrong toolchain.
In version 12, the toolchain object we get has all the LLVM paths in it (includes, cc_wrapper and so on), all pointing to (bazel info output_base)/external/llvm_toolchain/....
With version 13, the latest bazel-toolchain and the incompatible_enable_cc_toolchain_resolution flag, the same call returns a different toolchain, where the compiler path is different and points to external/local_config_cc/wrapped_clang. The object includes none of the LLVM paths.
In addition to returning the wrong toolchain, I also noticed that all paths are now relative, whereas when using version 12 they are all absolute.

It sounds like toolchain resolution is giving you back the toolchain installed on your machine instead of the one from bazel-toolchain.
Did you also remember to add a call to llvm_register_toolchains() in your WORKSPACE?
In case you haven't already come across it, these docs do a good job explaining toolchains, toolchain resolution, and how rulesets should use toolchains. For C/C++ toolchains the actual toolchain lookup (ctx.toolchains) is handled for you by find_cpp_toolchain in a way that's compatible with both workspaces that are and are not using toolchain resolution.
Making the changes described in ^ (i.e. using ctx.toolchains instead of the legacy hidden attribute) isn't required to use toolchain resolution for C/C++ but if you do end up making those changes you may also want to add incompatible_use_toolchain_transition = True to your rule definition.
Building a target that uses that rule with --toolchain_resolution_debug can also be a good way to try to figure out exact why Bazel is picking another toolchain to give to that rule.

In the Bazel issue linked in the README describing the migration for incompatible_enable_cc_toolchain_resolution, they mention that find_cpp_toolchain has been deprecated and that we should instead use find_cc_toolchain.
I tried doing the migration, making sure that the rules depended on the right toolchains and that we were now using the new rules_cc dependency. Unfortunately, this did not fix the problem and the new find_cc_toolchain still returns the same incorrect response.

I'm fairly confident this is unrelated; find_cpp_toolchain in @rules_cc is "deprecated" but just calls find_cc_toolchain anyways and #rules_cc's find_cc_toolchain is essentially a verbatim copy of @bazel_tools's. Both have the logic to use ctx.toolchains when C/C++ toolchain resolution is enabled. (there used to be a bug in the @rules_cc impl caused by a bug in how Bazel handles aliases in string form labels when used with ctx.toolchains but it's since been "fixed" with this workaround; just make sure you're using a version of @rules_cc newer than that commit if you're planning to keep your @rules_cc changes).

@rrbutani once again, thank you for the quick and detailed response. I indeed had forgotten to invoke llvm_register_toolchains in the branch I'm working on the LLVM upgrade. I apologize for the confusion, I'm working on multiple branches and got lost. Invoking llvm_register_toolchains fixes the issues with finding the right toolchains.
I'm now hitting one last error before successfully compiling the custom Ruby build. One of Ruby's arguments during compilation is -install_name @execution_path/../lib/libruby.2.7.dylib. The error is
.../llvm_toolchain_13_0_0/bin/cc_wrapper.sh: line 54: executable_path/../lib/libruby.2.7.dylib: No such file or directory

The reason this happens is because the cc_wrapper tries to read the paths for arguments beginning with @ here. However, Ruby adds the install_name flag when compiling libruby.2.7.dylib itself, which means the file indeed doesn't exist at that step. The command has this form
.../cc_wrapper ... -install_name @execution_path/../lib/libruby.2.7.dylib -o libruby.2.7.dylib

Notice that the file not existing only fails because cc_wrapper tries to read it. Invoking clang directly from the llvm_toolchain_llvm/bin folder works. Commenting out the part of cc_wrapper that attempts to read paths starting with @ also makes the build succeed. The step that tries to read the paths was added in #97.
Do you have any context as to why that is necessary or if we can workaround it somehow?

I apologize for the confusion, I'm working on multiple branches and got lost. Invoking llvm_register_toolchains fixes the issues with finding the right toolchains.

No worries! Glad to hear it was a simple fix.

I'm now hitting one last error before successfully compiling the custom Ruby build. One of Ruby's arguments during compilation is -install_name @execution_path/../lib/libruby.2.7.dylib. The error is
.../llvm_toolchain_13_0_0/bin/cc_wrapper.sh: line 54: executable_path/../lib/libruby.2.7.dylib: No such file or directory

The reason this happens is because the cc_wrapper tries to read the paths for arguments beginning with @ here. However, Ruby adds the install_name flag when compiling libruby.2.7.dylib itself, which means the file indeed doesn't exist at that step. The command has this form
.../cc_wrapper ... -install_name @execution_path/../lib/libruby.2.7.dylib -o libruby.2.7.dylib

Notice that the file not existing only fails because cc_wrapper tries to read it. Invoking clang directly from the llvm_toolchain_llvm/bin folder works. Commenting out the part of cc_wrapper that attempts to read paths starting with @ also makes the build succeed. The step that tries to read the paths was added in #97.
Do you have any context as to why that is necessary or if we can workaround it somehow?

This is a good catch!
That snippet was added to support parameter files.
The macOS cc wrapper script inspects the full command line in order to remap libraries that are being linked against to their fully resolved paths, taking into account the rpaths added to the binary. I don't have first-hand experience with this but this is allegedly because of some oddness having to do with runpaths added to binaries (this has some context; I think it's that the paths are relative to the build dir and not the workspace that's causing the issue but I have no idea what's introducing the -Wl,-rpaths in the first place).
Anyways, for that reason we need to actually read what's in the parameter file. The PR in this repo you linked to was essentially copied from upstream (this commit); in general the logic in the macOS wrapper mostly comes from upstream.
The issue here, of course, is that the @ in -install_name @execution_path/... does not signify a parameter file!
What's peculiar to me is that upstream Bazel seems to fail on this in the exact same way (here's a minimal test case). Perhaps it's simply not common for users to want to generate dylibs with install_paths from Bazel and it hasn't come up? Not sure.

I think extending the logic in the macOS wrapper to skip processing args starting with @ (like @execution_path/..., @executable_path/..., @load_path/.., @rpath/..., etc.) when the preceeding arg is -install_name or -rpath would fix the error you're running into.
I have a few concerns though:

is this genuinely an error with the default Bazel toolchain? does the workspace you're building work without bazel-toolchain or with any other toolchains?
are -install_name and -rpath the only args that accept @ form args?
what kind of path remapping should we be doing for -install_name and -rpath?

I think the answer is "none" for -install_name but what about -rpath? Don't we have the same issues as with -Wl,-rpath? -rpath certainly does seem to just expand out into -rpath to the linker, experimentally. Are we just banking on users using the not-macOS specific -Wl form?

why does the logic in the wrapper only use @loader_path?

@vinistock If possible, it'd be super helpful if you could point me to where in your workspace that flag is getting added.

Actually, I'm going to open a new issue for this.

I worked through some more investigations on this and thought I'd bring up another thing I'm seeing. I'm trying to change a dependency of a package by matching on a config_setting that uses platform constraint values. Basically, we need a different dependency on darwin-arm64.
The code I have on a Sorbet branch is equivalent to this:
# BUILD file

platform(
    name = "darwin_arm",
    constraint_values = [
        "@platforms//cpu:arm64",
        "@platforms//os:osx",
    ]
)

platform(
    name = "darwin_x86",
    constraint_values = [
        "@platforms//cpu:x86_64",
        "@platforms//os:osx",
    ],
)

config_setting(
    name = "darwin",
    constraint_values = [
        "@platforms//cpu:x86_64",
        "@platforms//os:osx",
    ]
)

config_setting(
    name = "darwin_arm64",
    constraint_values = [
        "@platforms//cpu:arm64",
        "@platforms//os:osx",
    ]
)

# Library BUILD file
cc_library(
  ...
  deps = select({
    "//:darwin": ["x86_specific_dependency"],
    "//:darwin_arm64": ["portable_version_dependency"],
    "//conditions:default": ["portable_version_dependency"]
  })
)

However, we always match //:darwin even when selecting the platform to be --platforms=@//:darwin_arm. If I remove the entry for darwin from the select, it falls under default and compiles successfully. Could this be related to the new toolchains?
This is the Sorbet branch I'm currently playing with if that helps.

@vinistock make sure that you are using a bazel arm64 release and not bazel amd64 running on rosetta. I think there is also a flag that help debug toolchain resolution that can be passed to bazel.

@sluongng you are right! I was indeed running an x86 version of bazel. Upgrading to 5.0.0 with an ARM64 executable seems to fix not only the issue with conditionally compiling the dependency, but also the -framework flag problem!!
I will spend some time validating it, but it looks like that was the issue all along.

I can confirm that using the ARM64 version of Bazel fixes the -framework issue and now the config_settings match properly. In the branch I'm working on, it's already possible to compile Sorbet in debug and release mode, as well as running some tests.
I am, however, having the same issue I was having before of the custom Ruby build selecting the wrong toolchains when using find_cpp_toolchain. This time, I'm sure I am invoking llvm_register_toolchains.
While debugging, I noticed that the arm64 toolchain is rejected by using the --toolchain_resolution_debug flag.
INFO: ToolchainResolution:     Type @bazel_tools//tools/cpp:toolchain_type: execution platform @local_config_platform//:host: Rejected toolchain //:clang-darwin-arm64-toolchain; mismatching values: x86_64

I was also able to confirm that changing the exec_compatible_with configuration in the toolchain from x86 to arm64 fixes the resolution and selects the right toolchain for the custom Ruby build. However, that breaks the regular Sorbet build.
toolchain(
    name = "clang-darwin-arm64",
    exec_compatible_with = [
        "@platforms//cpu:x86_64", # If this value is x86_64, the toolchain is rejected. If we use arm64, the toolchain is selected
        "@platforms//os:osx",
    ],
    target_compatible_with = [
        "@platforms//cpu:arm64",
        "@platforms//os:osx",
    ],
    toolchain = ":clang-darwin-arm64-toolchain",
    toolchain_type = "@bazel_tools//tools/cpp:toolchain_type",
)

I'm not sure why, when using exec_compatible_with x86, the right toolchain is selected for Sorbet, but not for the Ruby build. Any ideas on what could be happening?

I checked it out and it works really nice!  (https://github.com/omerbenamram/bazel-toolchain/tree/llvm-15.0.0)
Unfortunately there are still no binaries for x86 linux (which is quite strage) for llvm 15.

I checked it out and it works really nice! (https://github.com/omerbenamram/bazel-toolchain/tree/llvm-15.0.0) Unfortunately there are still no binaries for x86 linux (which is quite strage) for llvm 15 - so I guess we can't upstream this yet.

15.0.2 does have a couple of x86 linux builds - i tested the RHEL on an ubuntu machine and it worked fine, so maybe we could just use that?

It looks like 15.0.3 was recently released, but unfortunately still does not include any x86_64 linux binaries.
For now, I'm used the patch provided by @iamricard and @omerbenamram. It seems to work well, with the addition of an extra patch to fix the strip_prefix for the clang+llvm-15.0.2-x86_64-unknown-linux-gnu-rhel86.tar.xz file. It seems to be only clang+llvm-15.0.2-x86_64-unknown-linux-gnu, missing the -rhel86 suffix.  I've only checked the darwin aarch64 and linux x86_64 builds though, so this may be the case with others.
I have an example standalone project using this toolchain here. It's focused on building cross-platform py3_image targets, so the use of this toolchain is really orthogonal to the purpose of the demo, but it may be useful to someone.
Full patch, in case that repo gets removed at some point:
diff --git a/toolchain/cc_toolchain_config.bzl b/toolchain/cc_toolchain_config.bzl
index 8785a8e..1ac65a5 100644
--- a/toolchain/cc_toolchain_config.bzl
+++ b/toolchain/cc_toolchain_config.bzl
@@ -68,6 +68,15 @@ def cc_toolchain_config(
             "clang",
             "darwin_x86_64",
             "darwin_x86_64",
+        ),
+         "darwin-aarch64": (
+            "clang-aarch64-darwin",
+            "aarch64-apple-macosx",
+            "darwin",
+            "macosx",
+            "clang",
+            "darwin_aarch64",
+            "darwin_aarch64",
         ),
         "linux-aarch64": (
             "clang-aarch64-linux",
diff --git a/toolchain/internal/common.bzl b/toolchain/internal/common.bzl
index 7493c64..53b3b53 100644
--- a/toolchain/internal/common.bzl
+++ b/toolchain/internal/common.bzl
@@ -12,7 +12,7 @@
 # See the License for the specific language governing permissions and
 # limitations under the License.

-SUPPORTED_TARGETS = [("linux", "x86_64"), ("linux", "aarch64"), ("darwin", "x86_64")]
+SUPPORTED_TARGETS = [("linux", "x86_64"), ("linux", "aarch64"), ("darwin", "x86_64"), ("darwin", "aarch64")]

 host_tool_features = struct(
     SUPPORTS_ARG_FILE = "supports_arg_file",
@@ -68,7 +68,10 @@ def arch(rctx):
     ])
     if exec_result.return_code:
         fail("Failed to detect machine architecture: \n%s\n%s" % (exec_result.stdout, exec_result.stderr))
-    return exec_result.stdout.strip()
+    arch = exec_result.stdout.strip()
+    if arch == "arm64":
+        return "aarch64"
+    return arch

 def os_arch_pair(os, arch):
     return "{}-{}".format(os, arch)
diff --git a/toolchain/internal/llvm_distributions.bzl b/toolchain/internal/llvm_distributions.bzl
index 074ed84..62011f3 100644
--- a/toolchain/internal/llvm_distributions.bzl
+++ b/toolchain/internal/llvm_distributions.bzl
@@ -207,6 +207,12 @@ _llvm_distributions = {
     "clang+llvm-14.0.0-x86_64-apple-darwin.tar.xz": "cf5af0f32d78dcf4413ef6966abbfd5b1445fe80bba57f2ff8a08f77e672b9b3",
     "clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz": "61582215dafafb7b576ea30cc136be92c877ba1f1c31ddbbd372d6d65622fef5",
     "clang+llvm-14.0.0-x86_64-linux-sles12.4.tar.xz": "78f70cc94c3b6f562455b15cebb63e75571d50c3d488d53d9aa4cd9dded30627",
+
+    # 15.0.2
+    "clang+llvm-15.0.2-arm64-apple-darwin21.0.tar.xz": "8c33f807bca56568b7060d0474daf63c8c10ec521d8188ac76362354d313ec58",
+    "clang+llvm-15.0.2-x86_64-apple-darwin.tar.xz": "a37ec6204f555605fa11e9c0e139a251402590ead6e227fc72da193e03883882",
+    "clang+llvm-15.0.2-aarch64-linux-gnu.tar.xz": "527ed550784681f95ec7a1be8fbf5a24bd03d7da9bf31afb6523996f45670be3",
+    "clang+llvm-15.0.2-x86_64-unknown-linux-gnu-rhel86.tar.xz": "f48f479e91ee7297ed8306c9d4495015691237cd91cc5330d3e1ee057b0548bd",
 }

 # Note: Unlike the user-specified llvm_mirror attribute, the URL prefixes in
@@ -229,6 +235,7 @@ _llvm_distributions_base_url = {
     "13.0.0": "https://github.com/llvm/llvm-project/releases/download/llvmorg-",
     "13.0.1": "https://github.com/llvm/llvm-project/releases/download/llvmorg-",
     "14.0.0": "https://github.com/llvm/llvm-project/releases/download/llvmorg-",
+    "15.0.2": "https://github.com/llvm/llvm-project/releases/download/llvmorg-",
 }

 def _get_auth(ctx, urls):
@@ -310,6 +317,9 @@ def _distribution_urls(rctx):

     strip_prefix = basename[:(len(basename) - len(".tar.xz"))]

+    if strip_prefix == "clang+llvm-15.0.2-x86_64-unknown-linux-gnu-rhel86":
+      strip_prefix = "clang+llvm-15.0.2-x86_64-unknown-linux-gnu"
+
     return urls, sha256, strip_prefix

 def _host_os_key(rctx):
diff --git a/toolchain/tools/llvm_release_name.py b/toolchain/tools/llvm_release_name.py
index 39505cc..3485d61 100755
--- a/toolchain/tools/llvm_release_name.py
+++ b/toolchain/tools/llvm_release_name.py
@@ -30,7 +30,12 @@ def _patch_llvm_version(llvm_version):

 def _darwin(llvm_version, arch):
     major_llvm_version = _major_llvm_version(llvm_version)
-    suffix = "darwin-apple" if major_llvm_version == 9 else "apple-darwin"
+    if major_llvm_version == 9:
+        suffix = "darwin-apple"
+    elif arch == "arm64":
+        suffix = "apple-darwin21.0"
+    else:
+        suffix = "apple-darwin"
     return "clang+llvm-{llvm_version}-{arch}-{suffix}.tar.xz".format(
         llvm_version=llvm_version, arch=arch, suffix=suffix)

@@ -86,6 +91,8 @@ def _linux(llvm_version, distname, version, arch):
     # If you find this mapping wrong, please send a Pull Request on Github.
     if arch in ["aarch64", "armv7a", "mips", "mipsel"]:
         os_name = "linux-gnu"
+    elif major_llvm_version == 15:
+        os_name = "unknown-linux-gnu-rhel86"
     elif distname == "freebsd":
         os_name = "unknown-freebsd-%s" % version
     elif distname == "suse":

@jbott It looks like 15.05 with linux binaires has been released.

I rebased @omerbenamram's change on top of the recent commits from this repo supporting 15.06 if anybody wants to use it: https://github.com/meastham/bazel-toolchain/tree/m1_support
Seems to be working fine

@meastham can you open a PR?

Sure: #174


See what we can learn from Bravais lattices

Here's the paper:
https://www.math.fsu.edu/~quine/MB_10/schattschneider.pdf

All of them have translation symmetry, so adding unit vectors to the spec (eventually) would make it so that all lattices can be represented.


License

I noticed this project doesn't have a license. Would it be possible to add one? It would make me feel more comfortable using it. :)
(The MIT License is always a good choice)

Done

Thanks!


Any plan for System.Text.Json?

Hello
Thank you guys for this awesome library
I would like to know if there is any plan to drop the Newtonjson serializer, and use the System.Text.Json?
Another idea would be to move the serializers outside the core project, and let the user choose which serializer to include,
example if I want to work with System.text.json I would import 2 packages: Docker.DotNet and Docker.DotNet.Text.Json.
Why?
1- The NewtonJson - Although it was a great library - will not support Aot
2- Remove a hard dependency from the core project
3- Performance of the System.Text...

mee too

Lack of AOT support is a deal breaker for me.  I had to resort to writing my own implementation.

Hey! Sorry for the delay.
Although it is going slowly (more slow than I would like tbh), I'm working on a full refactory of the library behind the scenes. I've made good progress but it is not ready for prime time yet.
This refactory, among other things, aims to:

Update everything to latest .Net
Drop JSON.Net and use System.Text.Json with Source Generators - Since the Docker APIs use JSON for serialization, it makes not much sense to have multiple JSON serializers and since STJ is miles away faster than JSON.Net and has Roslyn Source Generators for the serializers, I'm sticking to it. The fact that all serializers will be source generated means that there is not reflection, so it is out of the box AoT friendly
Drop the handmade Go model generator - The new version uses Roslyn source generator on top of the publicly available Docker API Swagger schema.  Will see.
Thanks for the interest and support, I'll keep everyone updated once I have more to share.

That sounds fabulous.  I appreciate the update and hard work!

@galvesribeiro can you share the repository please? even if it's not ready yet

Honestly, I think a better route would be to bind to Podman's libpod API and transition away from using Docker whatsoever, as Docker has been lagging behind as a container runtime. The API in question

@kanpov Docker is not going anywhere tbh. Yes, it is slow moving than other newcomer libraries.
I thought however, on having (after the revamp on Docker.DotNet) other container runtime library support like for example, containerd, maybe podman. Perhaps rebranding Docker.DotNet to Container.DotNet. I'll discuss with others and perhaps open a pool somewhere to see if this would be a good idea but first, need to finish the revamp the current library.

Somehow I missed @galvesribeiro comment who said he was working on a full refactoring so I went ahead with #672 which replaces Newtonsoft.Json with System.Text.Json. Maybe it can help move forward.

@0xced I've merged your PR as a temporary step. We will optimize it later. Thank you!


Change the default behavior of get_show_sql to avoid wrapping in subquery

Context:

https://github.com/dbt-labs/dbt-core/issues/9600
internal slack thread

Implementation:

By default, get_show_sql should not wrap in a subquery. Instead, it should simply append limit {{ limit }} to the end of the query.
This does not work for queries that already contain a limit clause, but it preserves ordering in all other cases.
Because this only changes the behavior for dbt show, which is a development (not production) workflow, I do not believe this needs to be gated behind a behavior change flag. Users can always opt back into the previous behavior by reimplementing get_show_sql within their projects.

{% macro get_show_sql(compiled_code, sql_header, limit) -%}
  {%- if sql_header -%}
  {{ sql_header }}
  {%- endif -%}
  {{ compiled_code }}
  {% if limit is not none %}
  limit {{ limit }}
  {%- endif -%}
{% endmacro %}

Acceptance tests:

I expect all existing tests to pass, since BaseShowLimit.test_limit is validating only that the limit is templated into the query (important!)
Ideally, we'd write a new test that reliably reproduces incorrect ordering when the query is wrapped in a subquery, and then prove that it is always correctly sorted. Unfortunately I haven't managed to come up with a simple reproduction case of this.

From estimation:

existing macro, same signature
not reimplemented in most adapters
could add a test for the known failure mode (limit repeated twice: once within actual query, once by supplying --limit flag)

See merge comments in #team-dev-adapters


ClassicsFooter 一直是展示 moMoreText

LoadedText and noMoreText are set in ClassicsFooter, but the display is always noMoreText. How is this display controlled?

+1

+1

+1

请了解异步原理。v2版本已重构


Define model classes to send errors to Raygun servers

Most models are defined already in the develop branch, based on the Android code

Done


RegExp flag s also applied to Flash

class Main {
	static function main() {
		var pat = ~/\{(.*)\}/s;
		var str = '{

			abc: 1,

			xyz: "adf",

			arr: ["a","b"]
		}
		';
		trace(pat.match(str) ? pat.matched(1) : "false");
	}
}

haxe -main Main -swf a.swf

I'm surprised there would be target differences with regards to this flag. I'll merge this for now but we should check if this is actually true.
Thanks!


mj-section. wrong background-color

Describe the bug
When I add two mj-sections (one of them has a full-width attribute) with an alpha background color, they have a different color.
To Reproduce
Steps to reproduce the behaviour:

Add code: <mjml>  <mj-head>  </mj-head>  <mj-body>      <mj-section background-color="rgba(8,20,222,0.5)">      </mj-section>    <mj-section full-width="full-width" background-color="rgba(8,20,222,0.5)">  </mj-section>  </mj-body> </mjml>

Put it to the https://mjml.io/try-it-live

See a differences

Or, just open the https://mjml.io/try-it-live/F-e5_701e2z

Expected behaviour
The colors should be the same in both cases
Screenshots
If applicable, add screenshots to help explain your problem.

I'm not sure we can really do something about it, for compatibility we need
sometime to put the background color on multiple levels to ensure it
display on as many clients as possible.
Most desktop clients doesn't support rgb/rgba colors it should be safer to
go with hex colors everywhere
On Thu, May 13, 2021 at 5:33 PM Oleksandr Reshetnikov <
@.***> wrote:

Describe the bug
When I add two mj-sections (one of them has a full-width attribute) with
an alpha background color, they have a different color.
To Reproduce
Steps to reproduce the behaviour:

Add code:

Put it to the https://mjml.io/try-it-live

See a differences
2.
Or, just open the https://mjml.io/try-it-live/F-e5_701e2z

Expected behaviour
The colors should be the same in both cases
Screenshots
If applicable, add screenshots to help explain your problem.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/mjmlio/mjml/issues/2257, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAELHTKCHOQ6YJB3N7DLTZ3TNPWMTANCNFSM442YKTGA
.

You're right. So, I will convert rgba to hex (6 digits) and replace it. Thanks


fix(registry): #5497 Label for disabled RadioGroupItem not showing as disabled

#5497

Thanks for this fix! fortunately I can just apply it to my code since it has not been merged

I +1 this. Please merge this


Key sound issue

I am not sure if it is related to keyboard or it is another iOS bug but some times keyboard sound get stuck. It keeps making sound without pressing any key, not able to switch off the sound. Only restart of device helps :)

Oh, that's not good. I've never run into it myself. Is it reproducible? What device?

I can not simulate the problem. it just happens sometimes. just keep using keyboard with sound enabled and you will see it one time :) i really believe that this is ios bug because looking at code we can see that there are no line of code that could do that. (or may be this is lack of some timer)

Hmm, the backspace timer might do that. Will check later...


chore: remove unused import

Hello Aleo team. ican help building this site if needed.

Thank you very much, only more substantial commits are appreciated to prevent spam.

Thank you very much, only more substantial commits are appreciated to prevent spam.

Thanks for the reply, I'm not mandating this is a meaningless fix. Perfect engineering practice needs to get rid of these “bad smells”. This would also block CI.


Fix cross-compiling with -d:windows -d:mingw

Dir separator is replaced with backslash. Use https://github.com/demotomohiro/pathX

I'm having the same issue - if I try using -d:mingw it fails, stating files cannot be found (due to backslash), while they are definitely present, using the proper forward slash.
❯ nim c -d:mingw --mm:orc -o:quarm_patcher.exe quarm_patcher.nim
Hint: used config file '/home/mcarter/.choosenim/toolchains/nim-2.0.0/config/nim.cfg' [Conf]
Hint: used config file '/home/mcarter/.choosenim/toolchains/nim-2.0.0/config/config.nims' [Conf]
.......................................................................................................................
/home/mcarter/.nimble/pkgs2/naylib-4.6.1-b8dba6d8ec2d85d03665077430f315612b508f4c/raylib.nim(97, 16) Error: cannot find: \home\mcarter\.nimble\pkgs2\naylib-4.6.1-b8dba6d8ec2d85d03665077430f315612b508f4c\raylib\src\rglfw.c
❯ ls -l /home/mcarter/.nimble/pkgs2/naylib-4.6.1-b8dba6d8ec2d85d03665077430f315612b508f4c/raylib/src/rglfw.c
-rw-r--r-- 1 mcarter mcarter 5421 Sep  4 15:46 /home/mcarter/.nimble/pkgs2/naylib-4.6.1-b8dba6d8ec2d85d03665077430f315612b508f4c/raylib/src/rglfw.c

Where my file (quarm_patcher.nim) has the contents of https://github.com/planetis-m/raylib-examples/blob/main/shapes/basic_shapes.nim sample and nothing else.

Also related, when building from Windows for the web target, currentSourcePath.parentDir returns "."

After adding these lines in raylib.nim:
when defined(mingw):
  import std/private/globs
  from std/private/ospaths2 import joinPath
  func `/`*(head, tail: Path): Path {.inline.} =
    joinPath(head.string, tail.string).nativeToUnixPath.Path
  {.passC: "-I/usr/x86_64-w64-mingw32/include".}
  {.passC: "-D_GLFW_X11".}

I am getting a ton of errors like:
In file included from /home/antonisg/Code/raydev/naylib/src/raylib/rglfw.c:73:
In file included from /home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/init.c:28:
In file included from /home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/internal.h:49:
In file included from /home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/../include/GLFW/glfw3.h:103:
In file included from /usr/x86_64-w64-mingw32/include/stddef.h:7:
In file included from /usr/x86_64-w64-mingw32/include/crtdefs.h:10:
In file included from /usr/x86_64-w64-mingw32/include/corecrt.h:10:
/usr/x86_64-w64-mingw32/include/_mingw.h:271:2: error: Only Win32 target is supported!
271 | #error Only Win32 target is supported!
    |  ^
In file included from In file included from /home/antonisg/Code/raydev/naylib/src/raylib/rglfw.c/home/antonisg/Code/raydev/naylib/src/raylib/rtext.c:73:
In file included from /home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/init.c:28:
In file included from /home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/internal.h:325:
In file included from :/home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/platform.h56::
81In file included from :
/home/antonisg/Code/raydev/naylib/src/raylib/raylib.hIn file included from :/home/antonisg/Code/raydev/naylib/src/raylib/external/glfw/src/x11_platform.h82::
28In file included from :
/usr/x86_64-w64-mingw32/include/stdarg.hIn file included from :/usr/x86_64-w64-mingw32/include/unistd.h140::
10:
/usr/x86_64-w64-mingw32/include/_mingw_stdarg.hIn file included from :/usr/x86_64-w64-mingw32/include/io.h11::102:
: /usr/x86_64-w64-mingw32/include/string.h:error: 51:3Only Win32 target is supported!:
error: '__declspec' attributes are not enabled; use '-fdeclspec' or '-fms-extensions' to enable support for __declspec attributes

It's an issue that should be fixed in nim, I am not going to concern myself with this


Functional: Fix Unsupported Python Version in CI

Description
Python 3.10.2 is not anymore available.
Requirements
Before submitting this PR, please make sure:

[x] You have run the code checks, tests and documentation build successfully
[x] All fixes and all new functionality are tested and documentation is up to date
[x] You looked at the review checklist

Additionally, if this PR contains code authored by new contributors:

[x] All the authors are covered by a valid contributor assignment agreement,
signed by the employer if needed, provided to ETH Zurich
[x] The names of all the new contributors have been added to an updated
version of the AUTHORS.rst file included in the PR

@egparedes was there a reason to pin to a patch version?

I think it was pinned to 3.10.0 in the first commit of the CI actions (maybe by @DropD ??, I'm not sure) for the functional branch and later updated to 3.10.1 and 3.10.2 whenever some error from that version was breaking CI or pre-commit. If it now works fine, I think it makes sense to avoid pinning the patch version.

Can we merge this as soon as possible? This issue breaks the whole functional CI, so would be nice if it would not stay open for too long… I don’t see any reason why the version is fixed to a specific release. This is only done for the pre-commit action, but not for the Tox action.

Thanks!


[Sprint: 41] XD-2562 Fixing dependency issues for running tests in STS

I ran ./gradlew install to build the spring-xd-module-parent pom and then ran the build for a couple of module projects. LGTM.


Update the game over message

Update the game over message so people know how to play again!

Bla bla bla, fix mistakes.


⚠ Buyfrom.io has degraded performance

In e4b5f03, Buyfrom.io ($BUYFROM_IO_URL) experienced degraded performance:

HTTP code: 200
Response time: 12925 ms

Resolved: Buyfrom.io performance has improved in abd6d42.


[Improve] Refactor update setting interface

What changes were proposed in this pull request
Issue Number: close #3578
Platforms such as Dcker Configuration and Alert Configuration lack parameter checks and are too arbitrary. Improve this by making the configurations for the different functions available as a complete form, so that they can be verified for completeness and compliance at submission time.

Brief change log

Verifying this change

This change added tests and can be verified as follows:

Added unit test to verify the change.

<!--*(example:)*

## Does this pull request potentially affect one of the following parts
 - Dependencies (does it add or upgrade a dependency): (no)

I'll merge the PR first, and later I'll submit a PR to fix it


feat: show warning if no machine is running or there are not enough resources (#227)

What does this PR do?
It shows a warning banner if the running podman machine does not have enough resources for the model selected by the user or if there is no running machine.
This needs https://github.com/containers/podman-desktop/pull/6733 to work
This PR only covers the inference server page to make the review easier. Going to open a new PR for the recipe page once it is merged
Screenshot / video of UI
This gif shows if you can edit the machine and if there is no running machine

This is the message if the edit action is not enabled for the system (like WSL)

What issues does this PR fix or reference?
Fixes #873
How to test this PR?

if you are on WSL you need to hack the result received from the system as it takes the resources from the host so you have to load the machine a lot to see the warning message
on MAC by creating a machine with few resources you should see the banner

Another general comment: here we are comparing the amout of free memory to the memory of the model but I think a little bit is required to run container(s). So I would apply a factor to the model memory before comparing to the free memory: what about:

+10% for inference server

25% for recipe (as we have several containers)

Another general comment: here we are comparing the amout of free memory to the memory of the model but I think a little bit is required to run container(s). So I would apply a factor to the model memory before comparing to the free memory: what about:

+10% for inference server

25% for recipe (as we have several containers)

25% seems a bit high to me. If you're using a model of 10GB it's like 2.5Gb more. Maybe we should have a threshold. Like 1GB. So if 25% is higher than 1GB we stick to 1GB, otherwise we use the 25%??

Another general comment: here we are comparing the amout of free memory to the memory of the model but I think a little bit is required to run container(s). So I would apply a factor to the model memory before comparing to the free memory: what about:

+10% for inference server

25% for recipe (as we have several containers)

used these values for the moment. We can update them later if we see some issue

Do we need a similar warning when starting an AI App? Currently, I don't get one when starting the ChatBot.

Not in this PR. I'm gonna create a new one when this is merged. But yes, there will be a similar warning when starting an AI app

I used the values as we do in desktop for the warning banner and this is the result
(the text and button are a sample, that text won't appear when the update button is visible)

One comment as I setup a small Podman machine so got the warning, updated the machine, so the warning disappear, then the model service is created, but once the service is created and running the warning is displayed again. Sounds strange but not false

Nice ! I really like with the warning instead of the error! Some remarks
* I see the banner inside the inference server creation form but not in the recipe page

* I am using latest version of podman, should I see the upgrade button ? Because I am not

warning-msg.mp4

There's a follow up PR for the recipe page (based ion your requirement for review :))-
Windows WSL does not support edit


fixed footer login link

Fixes https://github.com/CircuitVerse/CircuitVerse/issues/1294
Describe the changes you have made in this PR -
Added if else condition in the footer that if a user is a login it will show  my circuits and if a user is not logged in then it will show the login
Screenshots of the changes (If any) -
If user is not logged in:

If user is logged in:

Note: Please check Allow edits from maintainers. if you would like us to assist in the PR.

Coverage remained the same at 84.279% when pulling 6aec0b7af3d07db6965baf86e8674b84fe1f479a on yash15601:login-link-in-footer into 49d81f0573b7afdd1aea61281c3094df84cf9f23 on CircuitVerse:master.

@nitin10s  @Ananthavijay  @satu0king review please


More pull request templates

The current template makes sense for the pyspec, but we should have one that is more amenable to @timbeiko's work on eth1 coordination.

What would we want to see?

FWIW, most changes I make are quite small, and the "template" that's most important is more the file template of things like london.md, berlin.md, etc.


Not work

./bin/php7/bin/php: error while loading shared libraries: /home/user/bin/php7/bin/../lib/libz.so.1: file too short

ok seems it's a missing dep or something, but try
https://github.com/ImagicalMine/ImagicalMine/blob/php7-0.14/compile-php7.sh
to compile the php7 bin, maybe this helps you.

Thanks, I compile php7 and its work fine!


pass temp setting ?

Hi,
i tried to use your plugin with Domoticz to setup a thermostat temperature. Settings can be set by passing them to the url
i want to know if it is possible to send the thermostat selected temp through the url ?
url is like this : http://<IP_ADDRESS>:8080/json.htm?type=command&param=switchlight&idx=104&switchcmd=Set Level&level=20
20 is the temp desired.

Hi there, you can see the API expectations in the README. This plugin does not contain native support for Domoticz, so it may be better to find one that does. Alternatively, you could fork this repository and change instances of the API calls to fit with your requirements.