Repository navigation
Release v3.1.1: fix macOS 27 SDK / Xcode 27 build break - #417
Conversation
LLVM 21's ld64.lld rejects TBD stubs that list arm64e.x1, so native macOS links fail with a cascade of missing libc++/libSystem symbols. Keep the override on the LLVM toolchain so wasm still uses wasm-ld. Co-authored-by: Cursor <cursoragent@cursor.com>
Patch apple_support 1.24.2 so wrapped_clang/libtool use macOS 11.0 and drop a dead nodiscard hasher call that shows up on every ASAN build. Co-authored-by: Cursor <cursoragent@cursor.com>
The upstream LLVM Linux-X64 archive's ld.lld is dynamically linked against libxml2.so.2. libxml2 2.14 moved to libxml2.so.16 and Ubuntu 26.04 (the next ubuntu-latest) ships no .so.2, so every link step fails with "error while loading shared libraries: libxml2.so.2". Use the host's /usr/bin/ld via the toolchain-scoped extra_link_flags, as already done on macOS, and disable supports_start_end_lib on Linux since GNU ld rejects --start-lib/--end-lib. The msan toolchain keeps ld.lld; its job stays on Ubuntu 22.04. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GNU ld resolves static archives in command-line order. toolchains_llvm puts -l:libunwind.a among the early link flags, ahead of libc++abi.a, so the switch from ld.lld left _Unwind_* undefined. Append the runtime archives in dependency order via extra_link_libs; a repeated static archive only supplies still-undefined symbols. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
@tameware , I will create a v3.1.1 tag and to the merge dance between main and develop once you have confirmed that the fix works on your system. |
There was a problem hiding this comment.
🟢 Approval recommended
The release changes are consistent, narrowly scoped, documented, and covered by configuration and platform build tests.
0 open findings
What changed in this PR
Fixes macOS 27 SDK linking and Xcode 27 ASAN warnings while improving Linux linker compatibility for release 3.1.1.
Changes:
- Selects native Apple/GNU linkers and supplies ordered Linux runtime archives.
- Patches
apple_supportcrosstool warnings with regression tests. - Bumps DDS to version 3.1.1 and documents the workarounds.
| File | Description |
|---|---|
.bazelrc |
Disables unsupported archive grouping for native linkers. |
BUILD.bazel |
Exposes patch files to configuration tests. |
MODULE.bazel |
Updates version, patches apple_support, and configures native linkers. |
MODULE.bazel.lock |
Refreshes dependency metadata. |
docs/BUILD_SYSTEM.md |
Documents macOS and Linux linker workarounds. |
library/src/api/dll.h |
Updates the public DDS version constant. |
patches/apple_support_libtool_nodiscard.patch |
Removes the unused nodiscard call. |
patches/apple_support_macos_min_11.patch |
Raises the helper deployment target. |
python/BUILD.bazel |
Registers the macOS ASAN configuration test. |
python/tests/ci_macos_asan_test.py |
Guards the apple_support patch configuration. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
LGTM. Works on my Mac with XCode 27.0 and MacOS Tahoe 26.6.2. I'm curious why it says "tameware and others added 5 commits [10 hours ago]". I'm only a reviewer on this one! |
|
Your name is mentioned because you contributed some of the commits that have been cherry-picked. |
Summary
v3.1.0/main, fixing the Bazel build break on macOS after upgrading to Xcode 27 / the macOS 27 SDK (ld64.lldcan't parse the new SDK's.tbdfiles — "unknown architecture arm64e.x1").develop, where this was already fixed via four small, independent commits (no conflicts, verified by building and testing this branch):deb44608Link Darwin binaries with Apple ld against the macOS 27 SDK.6ff9bd44Silence Xcode 27 apple_support crosstool warnings under ASAN.20d97b4dLink with GNU ld on Linux instead of the LLVM archive's ld.lld85770509Repeat libc++/libc++abi/libunwind at the end of Linux linksMODULE.bazel→3.1.1,DDS_VERSION→30101), matching thev3.1.0release commit's own pattern.developso it stays a minimal patch release.Why cherry-pick instead of reimplementing
This fix already exists in
develop. Cherry-picking the exact same commits (rather than an independent reimplementation) means the final file content forMODULE.bazel/.bazelrc/docs/BUILD_SYSTEM.mdis byte-identical to what's already upstream, so mergingmainback intodevelopafter this release is a conflict-free no-op for these files.Test plan
bazelisk test //library/... //python/...— 68/68 passbazelisk test --config=asan //library/tests/system:context_tt_facade_test— pass (this is the path the apple_support patches target)main, then tagv3.1.1mainback intodeveloppost-tag to keep history linked (should be conflict-free per the above)🤖 Generated with Claude Code