From a3d913357baf824f0fee43431d49419c873ec11c Mon Sep 17 00:00:00 2001 From: Emi Date: Thu, 3 Sep 2026 13:43:59 -0700 Subject: [PATCH] fix: make macOS release builds work on Apple Silicon Before this change, the macOS release job failed on the arm64 runner: ``` clang: error: include path for libstdc++ headers not found [-Werror,-Wstdlibcxx-not-found] ``` After this change, we unblock release jobs: release-mac builds for the host architecture instead, so that macOS release artifacts are genuinely arm64 (as the README and gem names claim, despite previously incorrectly being x86_64 binaries.) toolchains_llvm is patched with a backport of upstream PR 686 (released in v1.7.0) that drops `-L/lib` on macOS; we can remove this patch when we upgrade later. Verified locally on arm64: `release-mac` and `dev` builds of `//main:scip-ruby` succeed, the release binary is arm64 with only system dylib deps, and `//gems/scip-ruby` produces both `arm64-darwin` gems. Signed-off-by: Emi --- .bazelrc | 2 +- docs/scip-ruby/CONTRIBUTING.md | 14 +---- third_party/externals.bzl | 5 ++ .../no_toolchain_lib_dir_on_macos.patch | 51 +++++++++++++++++++ 4 files changed, 58 insertions(+), 14 deletions(-) create mode 100644 third_party/toolchains_llvm/no_toolchain_lib_dir_on_macos.patch diff --git a/.bazelrc b/.bazelrc index 7e7b7bd6d..ecd60fcfd 100644 --- a/.bazelrc +++ b/.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 diff --git a/docs/scip-ruby/CONTRIBUTING.md b/docs/scip-ruby/CONTRIBUTING.md index 2409252ab..5148c08f9 100644 --- a/docs/scip-ruby/CONTRIBUTING.md +++ b/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: diff --git a/third_party/externals.bzl b/third_party/externals.bzl index 1f64931d9..45f5ad867 100644 --- a/third_party/externals.bzl +++ b/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( diff --git a/third_party/toolchains_llvm/no_toolchain_lib_dir_on_macos.patch b/third_party/toolchains_llvm/no_toolchain_lib_dir_on_macos.patch new file mode 100644 index 000000000..ba02bfd9f --- /dev/null +++ b/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/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 = [