fix: make macOS release builds work on Apple Silicon

.bazelrc

@@ -143,7 +143,7 @@ build:release-linux           --copt=-march=sandybridge
 build:release-sanitized-linux --copt=-march=sandybridge
 build:release-linux-aarch64   --copt=-march=armv8.1a
 
-build:release-mac --config=release-common --platforms=@//tools/platforms:darwin_x86_64
+build:release-mac --config=release-common
 
 build:release-debug-linux --config=release-linux
 build:release-debug-linux --config=release-debug-common

docs/scip-ruby/CONTRIBUTING.md

@@ -424,19 +424,7 @@ For a source repo, cloning the repo and running `scip-ruby-autoindex` should do
              ^
     2 errors generated.
     ```
-2. A release build (`--config=release-mac`) fails on Apple Silicon Macs,
-   which (I think) is related to this upstream
-   [jemalloc issue](https://github.com/jemalloc/jemalloc/issues/1997),
-   which is mentioned to be caused due to a QEMU bug. It manifests as an error:
-   ```txt
-   include/jemalloc/internal/rtree.h:118:3: error: constant expression evaluates to -12 which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing]
-      {RTREE_NSB, RTREE_NHIB + RTREE_NSB}
-       ^~~~~~~~~
-    include/jemalloc/internal/rtree.h:22:19: note: expanded from macro 'RTREE_NSB'
-      #define RTREE_NSB (LG_VADDR - RTREE_NLIB)
-                ^~~~~~~~~~~~~~~~~~~~~~~
-   ```
-3. Using Xcode 14 can trigger a build error inside the C++ toolchain config.
+2. Using Xcode 14 can trigger a build error inside the C++ toolchain config.
    ```text
    File "/private/var/tmp/_bazel_xyz/0eec049f96822615c65f9acc22fdf113/external/local_config_cc/cc_toolchain_config.bzl", line 45, column 25, in _can_use_deterministic_libtool
            if _compare_versions(xcode_version, _SUPPORTS_DETERMINISTIC_MODE) >= 0:

third_party/externals.bzl

@@ -187,6 +187,11 @@ def register_sorbet_dependencies():
         url = "https://github.com/bazel-contrib/toolchains_llvm/releases/download/v1.5.0/toolchains_llvm-v1.5.0.tar.gz",
         sha256 = "49e69c011bcaa4c9a7246a287ab1fb4f7ed3fde7cbd7300374c1030f40d2bb95",
         strip_prefix = "toolchains_llvm-v1.5.0",
+        patches = [
+            # Backport of https://github.com/bazel-contrib/toolchains_llvm/pull/686;
+            # remove when upgrading to toolchains_llvm >= v1.7.0.
+            "@com_stripe_ruby_typer//third_party:toolchains_llvm/no_toolchain_lib_dir_on_macos.patch",
+        ],
     )
 
     http_archive(

third_party/toolchains_llvm/no_toolchain_lib_dir_on_macos.patch

@@ -0,0 +1,51 @@
+Backport of https://github.com/bazel-contrib/toolchains_llvm/pull/686
+(merged 2026-02-25, first released in toolchains_llvm v1.7.0).
+
+On macOS, the -L<toolchain>/lib link flag lets Apple's ld64 discover the
+toolchain's libunwind.1.dylib (via the libunwind re-export in the SDK's
+libc++abi.tbd) and bake it into binaries as @rpath/libunwind.1.dylib, which
+fails at runtime with "dyld: Library not loaded". This only shows up with
+--spawn_strategy=local, which our debugsymbols/backtracesymbols configs use.
+Drop this patch when upgrading toolchains_llvm to >= v1.7.0.
+
+diff --git toolchain/cc_toolchain_config.bzl toolchain/cc_toolchain_config.bzl
+--- toolchain/cc_toolchain_config.bzl
++++ toolchain/cc_toolchain_config.bzl
+@@ -287,19 +287,30 @@
+             # libc++abi, so static linking them becomes a problem. We need to
+             # ensure that they are dynamic linked from the system sysroot and
+             # not static linked from the toolchain, so explicitly have the
+-            # sysroot directory on the search path and then add the toolchain
+-            # directory back after we are done.
++            # sysroot directory on the search path.
++            #
++            # The toolchain lib directory is intentionally NOT added to the
++            # search path here. In sandboxed execution, the toolchain's lib/
++            # directory is empty (only declared outputs are present), so the
++            # previous -L flag was a harmless no-op. However, with
++            # --spawn_strategy=local, the full toolchain lib/ directory is
++            # visible to the linker, and ld64 discovers dylibs like
++            # libunwind.1.dylib via the -L search path. These get baked into
++            # the binary as LC_LOAD_DYLIB entries with @rpath install names
++            # that fail at runtime because the toolchain directory is not in
++            # the binary's @rpath search path.
++            #
++            # libunwind_link_flags is left empty on macOS because libunwind
++            # is unconditionally provided by libSystem.B.dylib (clang always
++            # passes -lSystem via Darwin.cpp). The toolchain's libunwind is
++            # redundant and its dylib causes the runtime failure described
++            # above, so the libunwind config flag has no effect on macOS.
+             link_flags.extend([
+                 "-L{}/usr/lib".format(sysroot_path),
+                 "-lc++",
+                 "-lc++abi",
+                 "-Bdynamic",
+-                "-L{}lib".format(toolchain_path_prefix),
+             ])
+-            libunwind_link_flags = [
+-                "-Bstatic",
+-                "-lunwind",
+-            ]
+
+     elif stdlib == "libc++":
+         cxx_flags = [