v0.0.84

修复

• clang 驱动配置文件(cfg)补全头文件搜索路径:fixup_clang_cfg 再生成的
  cfg 此前仅包含链接相关条目(-B/-L/动态链接器/rpath),缺少 C 标准库头文件
  与内核头文件的搜索路径。该 cfg 服务于直接调用打包内 clang/clang++
  (不经由 mcpp)的场景:缺少这两项时,此类调用仅在宿主系统存在
  /usr/include 时可编译(依赖宿主环境,违背沙箱自包含约束),在无宿主开发头
  文件的环境中直接报头文件缺失错误。本次补充
  -isystem <glibc payload>/include 与 -isystem <linux-headers payload>/include,
  置于 libc++ 头文件条目之后以保持 #include_next 搜索链;生成内容与
  xim-pkgindex 侧 llvm.lua 安装期生成的 cfg 保持一致,消除两个生成端之间的
  内容差异。fixup 修订号升级至 hermetic-3,既有 payload 在下一次构建时自动
  重新收敛,无需重新安装。验证方式:以 --sysroot=<空目录> 屏蔽宿主头文件后,
  由 cfg 驱动的 clang/clang++ 直接调用编译与运行均通过;移除上述搜索路径的
  对照组按预期失败。mcpp 自身构建路径不受影响(构建 flags 由 linkmodel
  独立提供,不读取 cfg)。

修复

• Linux llvm 工具链链接失败 cannot open Scrt1.o/crti.o/crtn.o(#195):clang-with-cfg
  的 payload 链接路径此前只带 -L/-rpath/--dynamic-linker,缺少 CRT 启动对象的发现前缀
  -B<glibc payload lib>——driver 查找 Scrt1.o/crti.o/crtn.o 只走 -B 前缀与 sysroot
  派生路径,不查 -L。在装有宿主 libc6-dev 的机器上 driver 会静默兜底宿主 /lib 的 CRT
  (污染式"假绿"),在没有的机器(如全新 WSL2)上则把裸文件名传给 lld 直接失败。

新增 / 架构

• 工具链链接模型单一化(hermetic toolchain link model):新增 mcpp.toolchain.linkmodel
  作为「如何对该工具链的 C 库编译/链接」的唯一解析器(payload-first,--sysroot 回退),
  flags / stdmod / build_program / cfg 再生全部消费同一模型,消除四份漂移实现;
  动态链接器名按 声明式 payload 元数据 → 按 triple 的 arch 映射 → glob 三级解析,全链
  不再硬编码 ld-linux-x86-64.so.2(aarch64 glibc 的 loader 障碍随之消除)。详见
  .agents/docs/2026-07-07-hermetic-toolchain-link-model-design.md。
• post-install fixup 归位为统一管线:ensure_post_install_fixup 成为所有工具链安装
  路径(显式 install / 默认工具链 auto-install / manifest [toolchain] auto-install)共享
  的唯一 fixup 入口,内容指纹 marker 幂等;此前 manifest 路径不跑任何 fixup。clang cfg
  由行级补丁改为从链接模型确定性再生(同一 payload 在任何机器/安装路径产出一致 cfg,
  人类直接使用 clang++ 同样获得 hermetic 的 CRT 发现)。
• hermetic 链接校验:构建前用 -### 干跑断言 CRT 对象与生效 dynamic linker 全部解析
  在沙箱(xpkgs registry)内,越界即报错并指明泄漏路径;逃生阀
  [build] allow_host_libs = true / MCPP_ALLOW_HOST_LIBS=1。按 flag 集缓存判定。
• 测试与 CI:新增 e2e 86_llvm_hermetic_link.sh(-### 前缀断言,双向防「链接失败」
  与「宿主污染」回归);llvm e2e 解除 20.1.7 硬 pin(MCPP_E2E_LLVM_VERSION,默认最新
  已装 payload);ci-linux-e2e 新增 无宿主工具链容器 job(debian:stable-slim,无 gcc /
  无宿主 CRT)——唯一能真实复现 #195 环境类的 CI 形态。

v0.0.83

修复

• Linux llvm 工具链链接失败 cannot open Scrt1.o/crti.o/crtn.o(#195):clang-with-cfg
  的 payload 链接路径此前只带 -L/-rpath/--dynamic-linker,缺少 CRT 启动对象的发现前缀
  -B<glibc payload lib>——driver 查找 Scrt1.o/crti.o/crtn.o 只走 -B 前缀与 sysroot
  派生路径,不查 -L。在装有宿主 libc6-dev 的机器上 driver 会静默兜底宿主 /lib 的 CRT
  (污染式"假绿"),在没有的机器(如全新 WSL2)上则把裸文件名传给 lld 直接失败。

新增 / 架构

• 工具链链接模型单一化(hermetic toolchain link model):新增 mcpp.toolchain.linkmodel
  作为「如何对该工具链的 C 库编译/链接」的唯一解析器(payload-first,--sysroot 回退),
  flags / stdmod / build_program / cfg 再生全部消费同一模型,消除四份漂移实现;
  动态链接器名按 声明式 payload 元数据 → 按 triple 的 arch 映射 → glob 三级解析,全链
  不再硬编码 ld-linux-x86-64.so.2(aarch64 glibc 的 loader 障碍随之消除)。详见
  .agents/docs/2026-07-07-hermetic-toolchain-link-model-design.md。
• post-install fixup 归位为统一管线:ensure_post_install_fixup 成为所有工具链安装
  路径(显式 install / 默认工具链 auto-install / manifest [toolchain] auto-install)共享
  的唯一 fixup 入口,内容指纹 marker 幂等;此前 manifest 路径不跑任何 fixup。clang cfg
  由行级补丁改为从链接模型确定性再生(同一 payload 在任何机器/安装路径产出一致 cfg,
  人类直接使用 clang++ 同样获得 hermetic 的 CRT 发现)。
• hermetic 链接校验:构建前用 -### 干跑断言 CRT 对象与生效 dynamic linker 全部解析
  在沙箱(xpkgs registry)内,越界即报错并指明泄漏路径;逃生阀
  [build] allow_host_libs = true / MCPP_ALLOW_HOST_LIBS=1。按 flag 集缓存判定。
• 测试与 CI:新增 e2e 86_llvm_hermetic_link.sh(-### 前缀断言,双向防「链接失败」
  与「宿主污染」回归);llvm e2e 解除 20.1.7 硬 pin(MCPP_E2E_LLVM_VERSION,默认最新
  已装 payload);ci-linux-e2e 新增 无宿主工具链容器 job(debian:stable-slim,无 gcc /
  无宿主 CRT)——唯一能真实复现 #195 环境类的 CI 形态。

v0.0.82

(no CHANGELOG entry found for 0.0.82)

v0.0.81

(no CHANGELOG entry found for 0.0.81)

v0.0.80

(no CHANGELOG entry found for 0.0.80)

v0.0.79

(no CHANGELOG entry found for 0.0.79)

v0.0.78

(no CHANGELOG entry found for 0.0.78)

v0.0.77

(no CHANGELOG entry found for 0.0.77)

v0.0.76

(no CHANGELOG entry found for 0.0.76)

v0.0.75

(no CHANGELOG entry found for 0.0.75)