Rust 1.99 直接链接失败

在 Apple Silicon Mac 上，工具直接调用 Rust 1.99.0 工具链目录里的 bin/rustc，链接 Wasm 动态库时报 Library not loaded: @rpath/libLLVM.dylib，rust-lld 随后因 SIGABRT 退出。同一工具链通过 rustup 入口调用却能链接时，应检查分发产物中的动态库路径。

这一分支针对 aarch64-apple-darwin 主机上的 Rust 1.99.0。它与缺少 Wasm 目标标准库、找不到系统链接器或业务符号未定义不同，不能只看到链接失败就安装另一份 LLVM。

编译器相同，启动环境可能不同

先保留完整的链接错误，确认缺失的库是 @rpath/libLLVM.dylib。在构建实际使用的环境中记录工具链身份和目录，例如下面两条只读命令；前提是项目已经安装并选用这一版本：

rustc +1.99.0 --version --verbose
rustc +1.99.0 --print sysroot

再检查构建工具究竟调用 rustup 管理的入口，还是直接执行 sysroot 中的 bin/rustc。单独在终端跑一次默认 rustc，不能证明 CI 或打包工具也经过同一入口。

受影响的 macOS 分发开始让 rust-lld 动态链接 LLVM。工具链把 libLLVM.dylib 放在顶层 lib/，链接器记录的相对查找路径却指向 lib/rustlib/aarch64-apple-darwin/lib/。直接启动编译器时，这个目录关系不能找到实际的库。

rustup 会给子进程的动态库搜索环境补上工具链的顶层 lib/，所以代理入口可能遮住这一分发问题。库文件仍可能存在；错误不等于整个工具链缺失或需要重新下载系统 LLVM。

保留版本，改用能提供正确环境的入口

如果项目已经由 rustup 管理工具链，且构建工具允许调整编译器入口，可采用明确选择 1.99.0 的 rustup 调用方式。rustup run 1.99.0 rustc 表示入口，后面仍须保留原来的完整编译参数、输入文件、目标、edition 和特性；不能只留下这段前缀就替换整条构建命令。

这项调整需要原工具链及相应目标已经安装，也需要构建工具把后续参数交给编译器，而不是把它们误当作自己的参数。验收仍从原来失败的构建入口进行，不能以另一个终端中的简化编译成功代替。

自带 sysroot、使用只读工具链目录或由其他分发系统管理的构建工具，应修正自己的产物布局或采用包含修复的正式产物。不要直接向这些目录写入符号链接，也不要用一份来源不明的系统 LLVM 覆盖工具链库。

全局设置 DYLD_LIBRARY_PATH 还可能改变其他程序加载的库。确需由工具管理子进程环境时，限制在该工具链与子进程范围，并考虑运行环境是否会过滤这些变量。

以正式产物和原构建验收为准

截至 2026 年 10 月 14 日，补充 Darwin 相对库路径的修复已经合入源码，稳定版回移也已获准；已核对的最新稳定版仍是 1.99.0。这些状态不能代替“正式补丁产物已经发布”的证据。

后续升级检查实际版本是否包含修复，保留原工具链选择与启动配置。恢复标准是同样的目标和编译参数在预定入口完成链接，缺库错误消失，CI 与本地使用的编译器身份符合项目要求。

需要撤回时恢复启动器或构建配置，不必删除 LLVM 文件或重写业务源码。如果错误已变成目标库缺失、架构不符或符号问题，就按新的报错继续调查。