Summary

Since the macos-latest runner image moved to Xcode 26.5 / clang 21, macos-check's cargo test --features full fails at the link step:

ld: library 'clang_rt.osx' not found

The cc link line already contains -L /Applications/Xcode_26.5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/21/lib/darwin and -lclang_rt.osx, but libclang_rt.osx.a is not present in that directory on the 26.5 image. The Xcode 26.5/clang 21 toolchain appears to have relocated or renamed the macOS clang_rt bundle.

Scope

• Not a regression in this crate. ort's static archive links against clang_rt (-lclang_rt.osx); the runtime provider is Xcode.
• Surfaced by fix(embedding): make dynamic-linking escape hatch work + guard static release link (#55) #56: switching --all-features → --features full made the static ort link real on macOS (previously --all-features enabled the broken embedding-fastembed-dynamic-linking, which skipped the static link entirely — so macos-check passed without ever linking the ONNX archive).
• The previous PR fix(embedding): make dynamic-linking escape hatch work + guard static release link (#55) #56 CI run (Xcode < 26.5) passed macos-check; rerunning on the 26.5 image fails deterministically.

Options to consider

1. Pin macos-check to macos-14 (Xcode 15.x, which ships clang_rt) until GitHub stabilizes the 26.5 image.
2. Resolve the clang_rt path on the 26.5 image (new location/name under clang 21) and inject it via RUSTFLAGS.
3. Keep macos-check non-blocking and rely on release-link-check (Linux/Windows static + ubuntu-22.04 dynamic) for the ort link regression guard, since macOS is the only target with this environment breakage.

Environment

• macos-latest runner, Xcode 26.5, clang 21
• ort =2.0.0-rc.12 (static archive), fastembed 5
• Discovered in PR fix(embedding): make dynamic-linking escape hatch work + guard static release link (#55) #56 (CI run https://github.com/epicsagas/llm-kernel/actions/runs/28744664406)