Skip to content

CHANGELOG.md

Latest commit

 

History

History
1358 lines (1249 loc) · 143 KB

CHANGELOG.md

File metadata and controls

1358 lines (1249 loc) · 143 KB
Raw

Changelog

维护说明：未发版的变更记录在 ## [Unreleased] 下；准备发版时，按 vX.Y.Z 标题格式将累计条目整理到对应版本节，并按改动性质归入 Added、Changed、Fixed、Docs 或 Chore。每条记录只保留用户和维护者 需要知道的主线变化，不逐行复制提交差异。

[Unreleased]

Added

  • mcpp.plugins 0.22.0。 dist-web 的页面是该格式唯一的可分发物，长期运行的 web 运行器（emrun）提供该目录并打开页面； 被拒绝的请求以警告陈述；mcpp 2026.11.16.1 起 dist-web 向引擎陈述它包装的程序（mcpp::pack_program，协议 19）， 多程序的包无需指名即打包该程序。包的下限仍为 mcpp 2026.10.30.1；latest 指向 0.22.0（mcpp-community/mcpp-plugins#54）。
  • openkal-platform 0.28.0。 增加四行：i686-linux-musl（Linux 的 32 位行）、x86_64-uefi（openkal-uefi 0.10.0 之上的 UEFI 应用， OVMF 下由 dirun 运行；ok 映像也可作为被承载程序打包为 UEFI）、i686-openkal（i386 的 ok 映像）与 i686-dos-musl（openkal-dos 之上的 DOS 程序， 仅为技术实验）。版本组随 openkal 0.25.3、openkal-macos 0.23.3、openkal-musl 0.29.6、openkal-llvm-runtime 0.20.3 与 openkal-image 0.6.3； 需要 mcpp 2026.11.14.1（mcpplibs/openkal-platform#31）。
  • djgpp-platform 0.1.0（新包）。 DJGPP 构建的 32 位 DOS 程序的平台包：行 i586-dos-djgpp（COFF 目标文件、.exe、ILP32、 执行系统 dos），其 GCC 由行的 GCC 目标 i586-pc-msdosdjgpp 指定（xim 包 i586-pc-msdosdjgpp-gcc 12.2.0），运行器为带 DOSBox Staging 配置的 dirun。仅 C：DJGPP 的 GCC 12.2.0 不支持 C++ 模块的依赖扫描。它与 openkal 的 DOS 路线 （openkal-platform 的 i686-dos-musl，社区默认）并存；需要 mcpp 2026.11.13.1（mcpplibs/djgpp-platform#1）。

Fixed

  • openkal-platform 0.28.1（版本组补丁）。 okrun、okld 与工具取 openkal-run/openkal-ld/openkal-tools 0.6.4（okrun 以 uname 指名目标）， C 库取 openkal-musl 0.29.7，openkal-macos 0.23.4；行与键不变（mcpplibs/openkal-platform#32）。

  • openkal-musl 0.29.7。 在 hosted 安排中，uname 的 sysname 报程序所运行的系统（Linux、FreeBSD、Darwin、Windows_NT、UEFI、MS-DOS）；ok 映像仍报 openkal（mcpplibs/openkal-musl#96）。

  • mcpplibs.mwrap.recastnavigation 1.6.0.2（包装修订 2）。 网格在每个平台上逐字节相同。1.6.0.1 的 Detour BV 树与 Recast 轮廓孔洞合并 用 C 库的 qsort 排序，qsort 不稳定，glibc、macOS、Windows UCRT 与 emscripten 对相等键的排列不同，带并列键的网格（网格状布局 很常见）因而得到不同的字节，其上的群体走到不同位置。补丁 0004 让这五处改用 std::stable_sort（同一比较函数，值得回馈上游）；新测试 钉住分成四块的柱网大厅的字节与群体状态，各平台一致。消费者测试 tests/mwrap/recastnavigation-path 改用 1.6.0.2。

  • openkal-emscripten 0.14.3。 描述符权限表（4096 个条目与 64 个根）的成员默认值为 -1，两张表因此是已初始化数据：每个 Web 构建的程序带着约 80 KiB 不会用到的字节（一个交付预算 4,000,000 B 的站点因此超出 9,332 B）。默认值全部改为零，取用的槽位再设哨兵； emsdk 6.0.9、-O2 下 g_entries 与 g_roots 从 .data 移到 .bss，行为不变（mcpplibs/openkal-emscripten#22）。

  • openkal-image 0.6.4（openkal-run、openkal-ld、openkal-tools、openkal-bind）。 okrun 在匹配前对每个映像名作词法规整，绝对名与相对名 一样：空分量（//）与 . 去掉，.. 去掉前一分量；此前绝对名原样匹配，含 // 的名字被拒绝。发布工作流在发布时自动运行，每个 发布都带产物，并增加 FreeBSD x86_64 与 aarch64（在 FreeBSD 机器中运行后附加）（mcpplibs/openkal-image#40）。

  • openkal-macos 0.23.4。 libSystem 的桩为 x86_64 列出 __bzero：clang 在该架构上把清零的 memset 降为 __bzero，无 SDK 的 链接因此失败，x86_64-macos-musl 的发布构建对任何程序都失败；CI 在 Linux 上链接、在 Intel Mac 上运行（mcpplibs/openkal-macos#50）。

  • mcpplibs.mwrap.recastnavigation 1.6.0.1（包装修订 1）。 群体的避障在每个平台上逐位相同。1.6.0 的 DetourCrowd 避障与 DetourTileCache 有向盒绕过 Detour 自己的钩子直接调用 C 库的 cosf、sinf，而钩子本身也转给 libm：glibc、macOS、Windows UCRT 与 emscripten 相差 一个 ulp，开启 DT_CROWD_OBSTACLE_AVOIDANCE 的群体因平台走到不同位置。三个补丁（patches/，预先应用在 upstream/， documents.json 记录每个文件在发布包中与打补丁后的校验和）：0001 改调 dtMathCosf/dtMathSinf（值得回馈上游）；0002 让钩子和 Recast 求坡度的 cosf 使用 port/DeterministicMath.cpp（只用 IEEE 运算，遍历全部 float 实测误差 0.500000001 ulp）；0003 修正 adaptiveDivs 为偶数时读取未初始化方向、32 方向 4 圈时写出数组末尾的上游缺陷（上游 issue #496、#798）。消费者测试 tests/mwrap/recastnavigation-path 改用 1.6.0.1。

  • openkal 0.25.3。 一致性套件是独立的 mtest 项目（tests/cts/mtest.toml）：引擎在套件目录启动程序并把运行记录存入 tests/cts/.mtest。0.25.2 下引擎取仓库根的项目，记录写入根存储，交给运行器（Web 上的 node）的程序名按错误的目录解析。 条款与声明无变化（mcpplibs/openkal#68）。

  • openkal-macos 0.23.3。 构建程序只在请求了目标且链接不带 SDK 时提供 libSystem 的替身；它读取 mcpp 的 MCPP_TARGET_SDK （mcpp 2026.11.14.1）。在 Mac 上以 --target aarch64-macos 构建时链接带 SDK，替身的名字不再遮蔽 SDK 的 libSystem （undefined symbol: strlen）；较早的 mcpp 不设该变量，沿用原条件（mcpplibs/openkal-macos#49）。

  • openkal 0.25.2。 一致性套件经弱引用到达每个名字而不要求其存在：丢弃无引用定义的链接保留实现所定义的名字，第 9 条的比较据此读取 （第 11 条第 63 项）。仓库的测试采用 mtest 布局（tests/unit、tests/e2e，套件位于 tests/cts，原 conformance/）； tools/run-conformance.sh 的调用方式不变。声明无变化，按 0.25.1 编写的实现仍然符合（mcpplibs/openkal#67）。

  • mcpplibs.mwrap.meshoptimizer 1.3.1（包装修订 1）。 库以 -ffp-contract=off、不开 fast math 编译：同样的输入在每个平台上逐位得到同样的 meshlet、聚类与简化结果。1.3 按平台默认编译，arm64 把乘与加合成一次舍入，打乱的 48 × 48 网格得到的 meshlet 与 x86-64 不同（由一个 消费者在 ubuntu-24.04-arm 上的测试发现）。上游源码不变；消费者测试 tests/mwrap/meshoptimizer-simplify 改用 1.3.1。

  • mtest 0.9.0. 四个包的 0.9.0（同一标签、同一归档）：选择文件的 !<id> 排除该用例及其声明的用例，?<id> 只在用例被声明时选中、 未声明时不报缺失；程序事件以 "selection": ["except", "optional"] 陈述这一能力（SPEC-017 P4.3，mcpp-community/mtest#24）。 运行器据此按用例声明的子用例划分一个长用例。不含 !、? 的选择行为不变。

  • mtest 0.8.5. 四个包的 0.8.5（同一标签、同一归档）：e2e::run 的结果在输出达到上限时如实说明——outcome 带回 out_truncated、err_truncated 与 held_open，command 可声明各输出的上限（out_limit、err_limit，默认值不变）， 失败的 succeeded、exited 指出被截断的输出及其长度（mcpp-community/mtest#22）。其余行为不变。

  • mtest 0.8.4. 四个包的 0.8.4（同一标签、同一归档）：测试程序在不能启动程序的系统上（wasm32-emscripten）可以链接——以命令探测的 能力在该目标上于编译期回答“不具备”，不再触及进程接口；0.8.0 至 0.8.3 在该目标上链接不出任何测试程序。其余目标不变。

  • compat.glfw：Win32 后端以 requires = { "mcpp:kernel-abi=windows" } 陈述它直接调用的系统接口。 MSVC 行、MinGW-w64 载荷与 mingw-w64-sysroot 基座都回答 windows，且本索引接受的每个 mcpp 版本都如此回答（载荷的 kernel-abi 即目标的系统）；openkal-musl 经 openkal-windows 的 Windows 身份回答 openkal，没有窗口系统，在解析期以该要求被拒绝，不再在 <windows.h> 处编译失败。 要求写在 c-abi=ucrt 上则会使 2026.11.3.1–2026.11.10.1 在 MSVC 上拒绝本包（这些版本对 MSVC 回答 msvc）。

  • compat.mimalloc：ok 映像不再链接 -lpthread、-lrt，Linux 不再链接 -latomic。 ok 映像（<arch>-openkal）原先读 linux 块，链接时找不到这两个归档；新增 openkal 块，不列链接参数。-latomic 上游只在找到时才链接，mimalloc 的原子操作在本索引 构建的各架构上都是无锁的，LLVM 工具链在图中 C 库之上没有这个归档。

Chore

  • CI 的 mcpp 由 2026.11.9.1 改为 2026.11.10.1（xpkgindex-update、openkal-compat 与 tests/openkal/pins.toml），以满足 openkal-image 0.6.0 的版本下限。

  • CI 的 mcpp 由 2026.11.7.2 改为 2026.11.9.1（xpkgindex-update、openkal-compat 与 tests/openkal/pins.toml），以满足 openkal-platform 0.24.5 的版本下限。

  • validate：llvm 腿不再从 Ubuntu 镜像安装 ffmpeg 开发包，改为在 /usr/include 下放置 FFmpeg 公开头文件同名、内容为 #error 的文件。 文件名取自 compat.ffmpeg 描述符所指发布（按描述符的 sha256 校验）。宿主头文件一旦被包含即在包含处报错， 比安装另一版本的头文件更直接地检验包含顺序；2026-11-06 起 ubuntu-26.04 运行器上 ffmpeg 依赖闭包（约 100 MiB）的下载在每个 超时内都完成不了。

Added

  • mcpplibs.mwrap.acl 2.1.0（新包）。 acl-m：Animation Compression Library 2.1.0（在给定误差内压缩骨骼动画片段与标量轨道， 并在任意时刻回放）及其固定的 Realtime Math 2.2.0 的 C++23 模块，以 export using 在上游的命名空间 acl、rtm、rtm::constants 里导出两库头文件的全部公开名字（197 个类型、454 个函数）；15 个内部链接的 constexpr 常量（k_invalid_track_index、 k_num_quality_tiers 等）以原名、原类型和原值位于 mcpplibs::mwrap::acl。导出清单由 clang 读头文件推出并在 CI 中审计。封装仓库 从上游发布包取源码（应用上游提交 0b06bd1 的一处修复），以 RTM_NO_INTRINSICS、ACL_NO_INTRINSICS、-ffp-contract=off、不用快速 数学构建：同一个片段在 Linux x86-64 与 arm64、macOS、Windows、wasm32 上，dev 与 release，压缩字节与回放姿态的哈希相同（钉住）。 不含 io（SJSON 读写）与引擎插件。消费者测试 tests/mwrap/acl-clip，安装后模板检查带 --deploy。GLOBAL 为 GitHub 发布资产， CN 为 GitCode mcpp-res/mwrap-acl 镜像，sha256 相同。

  • mcpplibs.mwrap.recastnavigation 1.6.0（新包）。 recastnavigation-m：Recast & Detour 1.6.0（由三角形构建导航网格、寻路、群体、 带障碍物的分块网格）的 C++23 模块，以 export using 在全局命名空间导出 Recast、Detour、DetourCrowd、DetourTileCache 头文件的 全部公开名字（99 个类型、75 个无作用域枚举的枚举项、170 个函数）；52 个内部链接的 static const 常量（DT_VERTS_PER_POLYGON、 DT_SUCCESS、RC_WALKABLE_AREA、RC_PI 等）以原名、原类型和原值位于 mcpplibs::mwrap::recastnavigation。导出清单由 clang 读头文件 推出并在 CI 中审计。封装仓库从上游 1.6.0 发布包取源码（不依赖 compat.recastnavigation：确定性要求库本身以 -ffp-contract=off、不用快速数学、各配置都定义 NDEBUG 编译，依赖的构建不接受消费者的这些标志；一个程序只链接两者之一），以这些标志构建：同一 组三角形与群体在 Linux x86-64 与 arm64、macOS、Windows、wasm32 上，dev 与 release，网格字节与群体位置的哈希相同（钉住）。不含 DebugUtils 与演示程序。消费者测试 tests/mwrap/recastnavigation-path，安装后模板检查带 --deploy。GLOBAL 为 GitHub 发布资产， CN 为 GitCode mcpp-res/mwrap-recastnavigation 镜像，sha256 相同。

  • mcpplibs.mwrap.jolt 5.6.0（新包）。 jolt-m：Jolt Physics 5.6.0（刚体与软体物理：形状、约束、查询、角色、载具）的 C++23 模块，以 export using 在上游的命名空间里导出 <Jolt/…> 下各头文件的全部公开名字（JPH 450 个类型、127 个函数与运算符、 6 个对象，及嵌套命名空间 ClosestPoint、HalfFloatConversion、ScaleHelpers、StreamUtils、literals 的名字）；50 个内部链接的 常量（cMaxPhysicsJobs、cDefaultConvexRadius、JPH_PI 等；常量数组为 std::array）以原名位于 mcpplibs::mwrap::jolt。导出清单 由 clang 读头文件推出并在 CI 中审计；JPH::FPControlWord 只在上游声明它的平台（SSE、Arm）导出。封装仓库从上游 5.6.0 发布包取 源码并以跨平台确定模式构建（JPH_CROSS_PLATFORM_DETERMINISTIC、-ffp-contract=off、不用快速数学，JPH_NO_DEBUG 使各配置相同）： 同一场景在 Linux x86-64 与 arm64、macOS、Windows、wasm32 上，dev 与 release，0、1、4 个工作线程，哈希相同（钉住）。不含调试 渲染器、性能剖析、对象流与 GPU 计算后端。消费者测试 tests/mwrap/jolt-world，安装后模板检查带 --deploy。GLOBAL 为 GitHub 发布资产，CN 为 GitCode mcpp-res/mwrap-jolt 镜像，sha256 相同。

  • mcpplibs.mwrap.basis_universal 2.50.1（新包）。 basis-universal-m：Basis Universal 2.50 转码器（把 KTX2 与 .basis 纹理转成 像素或 GPU 自己的压缩格式）的 C++23 模块，<transcoder/basisu_transcoder.h> 在 basist、basisu 及其内部命名空间声明的 603 个名字（148 个类型、273 个函数、70 个对象、112 个无作用域枚举的枚举项）以原名导出；头文件里 139 个内部链接的标量常量 以原名位于 mcpplibs::mwrap::basis_universal::<所在命名空间>，11 个无法重新给出的内部链接名字（static 函数、常量表、 非常量表达式的 const float）留给头文件。封装仓库逐字节收录 v2_50 发布包的 transcoder/ 与上游随附的 Zstandard 解码器 （zstd/zstddeclib.c），按上游默认方式构建（全部格式、KTX2、Zstandard），关闭浮点收缩；不含编码器。封装的测试读取上游 自己的 KTX2 测试文件：ETC1S 照片转成 RGBA 像素与 BC7、ETC2、ASTC 块的哈希在四个平台行一致，同一幅 XUASTC 图的两种打包 给出同一幅图。消费者测试 tests/mwrap/basis-universal-transcode，安装后模板检查带 --deploy。GLOBAL 为 GitHub 发布资产， CN 为 GitCode mcpp-res/mwrap-basis-universal 镜像，sha256 相同。封装修订 2.50.1（2.50 保留）：在每个目标上都启用不透明块的 较大 ASTC 表（上游在 Emscripten 下关闭它），编译为 WebAssembly 时的 ASTC 块与原生构建相同；平台列表加入 emscripten。

  • mcpplibs.mwrap.libjpeg_turbo 3.2.1（新包）。 libjpeg-turbo-m：libjpeg-turbo 的 TurboJPEG API（JPEG 压缩、解压、无损变换）的 C++23 模块，<turbojpeg.h> 的 7 个枚举、68 个枚举值、4 个类型、80 个函数以原名导出；头文件里的 43 个常量宏、9 个 static const 常量与表、3 个带参数的宏（tj3Init、TJSCALED、TJPAD）以原名位于 mcpplibs::mwrap::libjpeg_turbo。 封装仓库逐字节收录 3.2.1 发布包中 TurboJPEG 静态库的源文件，按上游的清单构建：不带 SIMD 扩展（C 代码，默认路径全程 整数运算，各平台结果相同）、libspng 链接 compat.zlib（上游的 WITH_SYSTEM_ZLIB）、关闭浮点收缩。封装的测试里上游的 testorig.jpg 解码结果与上游回归测试期望的 MD5 一致。消费者测试 tests/mwrap/libjpeg-turbo-decode，安装后模板检查带 --deploy。GLOBAL 为 GitHub 发布资产，CN 为 GitCode mcpp-res/mwrap-libjpeg-turbo 镜像，sha256 相同。

  • mcpplibs.mwrap.manifold 3.5.5.1（新包）。 manifold-m：Manifold（始终保持流形的实体几何库）的 C++23 模块，以 export using 在上游的命名空间里导出 <manifold/manifold.h> 与 <manifold/polygon.h> 的全部公开名字（manifold 36 个类型、10 个函数， manifold::math 16 个函数，linalg 10 个类型、116 个函数与运算符）；7 个内部链接的 constexpr 常量（kPi、 DEFAULT_SEGMENTS、linalg::identity 等）以原名位于 mcpplibs::mwrap::manifold。导出清单由 clang 读头文件推出并在 CI 中审计。 封装仓库从上游 3.5.5 发布包取源码并自行构建：与上游一样关闭浮点收缩（封装修订 3.5.5.1 补上，3.5.5 未入索引）， 单线程（MANIFOLD_PAR=-1，不依赖 oneTBB），同样的输入在各平台给出逐位相同的三角形（次序随标准库的排序而不同），不含 CrossSection（上游实现依赖 Clipper2，3.5.5 中不依赖它的后端只是占位）。消费者测试 tests/mwrap/manifold-boolean，安装后模板检查带 --deploy。 GLOBAL 为 GitHub 发布资产，CN 为 GitCode mcpp-res/mwrap-manifold 镜像，sha256 相同。

  • mcpplibs.mwrap.meshoptimizer 1.3、mcpplibs.mwrap.cgltf 1.15（新包）。 两个 mwrap 包：meshoptimizer-m 以 export using 导出 <meshoptimizer.h> 的全部公开名字（9 个类型、20 个枚举值、89 个函数），MESHOPTIMIZER_VERSION 在 .macros 中为同名常量； cgltf-m 导出 <cgltf.h> 的全部公开名字（72 个类型、102 个枚举值、37 个函数），并再导出 .write（<cgltf_write.h>）。 本索引没有这两个库的 compat 包，封装仓库各自从上游发布包取源码（校验和在 upstream/documents.json）并自行构建；导出清单由 各仓库的 tools/surface.py 从头文件推出并在 CI 中审计。消费者测试 tests/mwrap/meshoptimizer-simplify、 tests/mwrap/cgltf-inspect，安装后模板检查带 --deploy（STATIC_NOTICES）；该检查读取生成的清单时同时接受带引号与 点分两种依赖键。GLOBAL 为 GitHub 发布资产，CN 为 GitCode mcpp-res/mwrap-<lib> 镜像，sha256 相同。

  • mtest 0.8.3. 四个包的 0.8.3（同一标签、同一归档；含未入索引的 0.8.1、0.8.2 的内容）：bench::each 的一次调用可以说明自己的组成 （part、time、value），给出最慢的几次、超过上限的次数与分配计数；bench::laps 是同一测量的循环形式； 程序单独运行时打印测得的数字，并按标识、名字或带 * 的模式选择用例。只增不改。

  • mtest 0.8.0. 四个包的 0.8.0（同一标签、同一归档）：用例以 only{}、except{} 陈述其运行的平台与架构（mcpplibs.os 的名字）， 在场所之外跳过并说明原因；capability 在代码中声明机器能力，由程序在任一运行器下回答；case 事件新增可选字段 only、except、capabilities、reason；mtest ci coverage 按用例陈述的场所检查。只增不改。

  • mtest 0.7.2. 四个包的 0.7.2（同一标签、同一归档）：mcpplibs.mtest.bench 新增 bench::each，逐次计时并给出分布（name、.p95、.p99、.max、.mean、.per_item）， 测量体可暂停并声明条目数；只增不改。

  • mtest 0.6.3. 四个包的 0.6.3（同一标签、同一归档）：mcpplibs.mtest.cts 让一致性套件对着一个主体运行 （cts::against、cts::needs）——用例需要而主体声明不具备的能力记为跳过（unsupported: …），既不算通过也不算失败； 运行要求而主体不具备的能力失败一次。协议不变。含 0.6.1（skip_exit：以退出状态判定的程序声明表示跳过的状态）与 0.6.2（源码写出的版本与清单一致）；这两个版本未单独收录。

  • openkal-platform 0.26.0。 hosted 部分增加 x86_64-freebsd-musl 与 aarch64-freebsd-musl：openkal-freebsd 0.1.0 standalone 之上的 openkal-musl 0.29.2，以及 openkal-llvm-runtime 0.20.1，链接为一个静态程序。版本组为 openkal-image 0.6.1、 openkal-musl 0.29.2、openkal-llvm-runtime 0.20.1 与 openkal-freebsd 0.1.0，运行器的宿主包含 FreeBSD；要求 mcpp 2026.11.10.1。 mcpp 2026.11.10.2 经此版本服务这两行。

  • openkal-freebsd 0.1.0（新包）、openkal-musl 0.29.1 与 0.29.2、openkal-llvm-runtime 0.20.1、openkal-image 0.6.0 与 0.6.1（openkal-run、 openkal-ld、openkal-bind、openkal-tools）、mtest 0.6.0（mcpplibs.mtest、.capi、.gtest、.manifest），一次变更。 openkal-freebsd 在 FreeBSD 的系统调用接口上实现 openkal，可与系统 C 库并存（hosted），也可置于 openkal-musl 之下 （standalone）；openkal-musl 与 openkal-llvm-runtime 增加 x86_64-freebsd-musl 与 aarch64-freebsd-musl 两行。 openkal-run 只绑定其实现提供的接口（mcpp 2026.11.10.1 的 MCPP_KERNEL_ABI_INTERFACES），0.6.1 在 FreeBSD 上以 openkal-freebsd 为缺省实现；openkal-musl 0.29.2 改用 openkal-ld ^0.6.0。mtest 0.6.0 实现 mcpp 测试 规范中每个用例的检查计数、输出与测试会话，并在入口中声明。

  • openkal-posix 0.1.0。 写在 POSIX C 库之上的 openkal 实现，为没有自身实现的系统服务；提供十五个接口（net、datagram、 prof、debug 不提供，名字不定义）；声明 requires = ["mcpp:c-abi"]。新增成员 tests/examples/openkal-posix（Linux、macOS）。

  • openkal-musl 0.29.0 与 openkal-llvm-runtime 0.20.0，一次变更。 musl 的 execvp、execvpe、execlp 与 posix_spawnp 按 kal_env_system 所述系统的约定查找程序（Windows：PATH 以 ; 分隔，无后缀的名字依次试 PATHEXT 各后缀）；link、linkat 经 kal_fs_hard_link 实现；声明 requires = ["mcpp:kernel-abi=openkal"]；依赖改为 openkal 0.25 一族。llvm-runtime 依赖 openkal-musl ^0.29.0，其测试改为 mtest 的用例。tests/examples/openkal-musl 与 tests/examples/openkal 改用新版本。

  • mcpplibs.os 0.4.4. 两个平台模块加入系统的对象模型：windows::com（COM 与 Windows Runtime：套间、对象与按槽调用、 query、create、hstring、activate、factory、delegate）和 macos::objc（Objective-C 运行时：id、send<R>、 autorelease pool、类与选择子、框架、NSString、define_class、block）；每个目标都声明、只在自己的平台定义，镜像里不定义； 库在首次使用时加载，不增加程序的链接输入（mcpplibs/os#24）。

  • openkal 0.25 一族，一次变更：openkal 0.25.0、openkal-kit 0.3.1、openkal-linux 0.26.0、openkal-macos 0.23.0、 openkal-windows 0.21.0、openkal-emscripten 0.14.0、openkal-opensbi 0.9.0。 规范新增 kal_fs_hard_link（按卷由 KAL_FS_PROP_HARD_LINKS 回答，条款 11 第 59 条），kal_process_stop_requested 的字改为计数每次结束请求（第 60 条）；一致性 套件按 mtest 测试协议报告，并核对实现清单的 provides-interfaces、kal_interfaces() 与导出名。各实现提供上述两项，测试改为 mtest 的用例；openkal-emscripten 声明 requires = ["mcpp:c-abi"]。tests/examples/openkal 改用此族，新增成员 tests/examples/openkal-kit 作为 kit 的直接使用者。kit 0.3.1 修正 format_v4 只写端口前三位数字的错误（8080 写作 080）。

  • mcpplibs.os 0.4.3. 依赖改为同时容纳 openkal 0.24 与 0.25 两族的版本区间（openkal >=0.24.0, <0.26.0，各实现同理）， mcpp 版本下限不变；openkal 实现以 mtest 测试自身时，经 mtest 到达 os 的图得以解析（mcpplibs/os#23）。

  • openkal-platform 0.24.5、openkal-image 0.5.4（openkal-ld、openkal-run、openkal-tools、openkal-bind）、mcpplibs.os 0.4.2， 一次变更。 openkal-run 以能力 mcpp:kernel-abi=openkal 声明其 openkal 实现，并按系统给出缺省实现（[defaults]）；图中已有的 实现优先。平台要求 mcpp 2026.11.9.1。os 0.4.2 新增 fs::watcher（mcpplibs/os#21），测试改为 mtest 的用例。

  • mcpplibs.cmdline 0.0.3. value_type<T>() 声明选项取 T 类型的数字，解析时用 std::from_chars 校验，不合法即解析错误； value_as<T>() 读回。测试成员移到 0.0.3，并检验这两项。

  • mtest 0.5.2. 四个包的 0.5.2：自启动副本的测试以对象 child 声明副本所做之事、以 child_command 启动之， 故不再定义 main，同一目录的文件可为一个程序；库对 mcpplibs.os 的要求为 ^0.4.1。测试成员移到 0.5.2。

  • mtest 0.5.1. 四个包的 0.5.1：协议标记在只保留可达部分的链接（--gc-sections）中保留，mcpp test 2026.11.9.1 以此链接测试程序。测试成员移到 0.5.1。

  • mtest 0.5.0. 四个包的 0.5.0（同一标签、同一归档）：一次运行为一张有向无环图，关键路径为其约束链；Markdown 报告 （mermaid 的图与甘特图）；每个用例的资源用量（[monitor]）；按用例跨进程调度；run 作用域夹具、资源池与组件。依赖 mcpplibs.os 0.4.1。测试成员移到 0.5.0。

  • mcpplibs.os 0.4.1. stdio::capture 在捕获期间把一个标准流保存为文件（经 openkal、C 库与期间启动的程序写出的内容）， text() 交回内容并恢复该流；process::resources 给出本程序及其已回收子程序的处理器时间、最大常驻集与读写字节数。 测试成员移到 0.4.1。

  • mtest 0.4.1. 四个包的 0.4.1（同一标签、同一归档）：返回值的用例体不能通过编译；静态清单跨源文件读取 项目自己的套件类型（types_of）；标签选择 a&b 表示同时具有两个标签的用例。测试成员移到 0.4.1。

  • mtest 0.4.0. mcpplibs.mtest、mcpplibs.mtest.gtest、mcpplibs.mtest.capi、mcpplibs.mtest.manifest 的 0.4.0 （同一标签、同一归档）：用例在名字之后声明其度量的界限（at_most、at_least），库在用例结束时判定（P6.5），列举、 静态清单与各适配器携带同一界限；引擎增加 analyze trend，并以替换字符保存非 UTF-8 的输出。测试成员移到 0.4.0， mtest 成员增加一个带界限的 Bench。

  • mtest 0.3.0. mcpplibs.mtest、mcpplibs.mtest.gtest、mcpplibs.mtest.capi 的 0.3.0 与新包 mcpplibs.mtest.manifest（同一标签、同一归档）：一个对象即一个用例，类型即类别（UTest、CTS、E2E、Bench， Suite 不声明类别），名字之后的属性说明它如何运行（资源、时限、隔离、重试、诊断）并由其声明的用例继承；静态用例 清单成为独立的包，读测试的工具不必链接测试库。测试成员 mtest、mtest-gtest、mtest-capi 移到 0.3.0，新成员 mtest-manifest 检验清单。

  • mtest 0.2.0. mcpplibs.mtest、mcpplibs.mtest.gtest、mcpplibs.mtest.capi 的 0.2.0（同一标签、同一归档）： mcpplibs.mtest.manifest 从源文本读出测试文件声明的用例（静态用例清单）；引擎增加 [discover.<name>] 组、 用例属性、--shard、覆盖映射与 list --static。测试成员 mtest、mtest-gtest、mtest-capi 随之移到 0.2.0。

  • mcpp.plugins 0.21.0。 CMake 交叉构建在动作运行时使用引擎给出的编译器、标志、归档器与目标约定（链接可执行文件或共享库的 交叉子项目需要 mcpp 2026.11.7.1）；加速器规则拥有各自的代码目标，SYCL 在一个请求中给出多个 NVIDIA 架构与 SPIR-V （mcpp#887）；plugins-progress 写出动作的可选进度；各成员经 mcpplibs.os 0.4.0 访问系统，不包含头文件。包的下限为 mcpp 2026.10.30.1；latest 指向 0.21.0。

  • mtest 0.1.0. mcpplibs.mtest, the C++ library of the mtest test system (cases, expectations, fixtures, bench, conformance and end-to-end helpers, no macro and no header, speaking the mtest test protocol); its GoogleTest adapter mcpplibs.mtest.gtest; its C ABI mcpplibs.mtest.capi. The three share one tag and one archive of mcpp-community/mtest, each descriptor naming its member's manifest. The test members mtest, mtest-gtest and mtest-capi consume them.

  • mcpplibs.os 0.4.0. is_openkal names a build for the openkal target, as each is_<platform> names its own (is_image remains as a deprecated alias); can_run_on(p) and on<P>(f) ask one platform question of a native build and an image alike; the platform modules are defined in an image where it can answer them; the effective user and the creation mask are the kernel's answers. The test member os consumes 0.4.0.

  • mcpplibs.os 0.3.1. A name in the long spelling (\\?\C:\..., \\?\UNC\...) is the name it spells: locate and every os::fs operation through it accept what fs::extended produces, which 0.3.0 refused with errc::invalid; the kernel layer is a compatible range. The test member os consumes 0.3.1 (it stayed on 0.2.9 when 0.3.0 was registered).

  • The openkal 0.24.2 patch group: a leaf and a platform patch, as one change. openkal-llvm-runtime 0.19.2 keeps the volume of a name it rebuilds part by part (lexically_normal, weakly_canonical, D:/a / /b), which 0.19.1 lost on Windows (openkal-llvm-runtime#68), and openkal-platform 0.24.2 names it; no other member changes. The test members openkal and openkal-platform consume the 0.24.2 group. Written by tools/family_release.py index of openkal-platform.

  • The openkal 0.24.1 correction group, as one change. openkal-platform 0.24.1, openkal-musl 0.28.1 (a directory's whole name kept, openkal-musl#83), openkal-llvm-runtime 0.19.1 (a name beneath a Windows volume is absolute, openkal-llvm-runtime#64) and the image family 0.5.1 (openkal-ld, -run, -tools, -bind: okrun over openkal-macos 0.22.1, indexed by #720). The members name one another by compatible ranges and the platform's version group selects the versions; this change was written by openkal-platform's tools/family_release.py index, which also verified each tag's GitHub archive against its GitCode mirror. The openkal members move to the group (runtime 0.19.1, platform 0.24.1, musl 0.28.1, the 0.5.1 image family).

  • mcpplibs.mwrap.zlib 1.3.2、.zstd 1.5.7、.xz 5.8.3、.xxhash 0.8.3、.libarchive 3.8.7、.libc 17.0.0（新包）。 六个 mwrap 包装把头文件收敛到各自的包中（mcpp 设计记录 2026-11-07 D10）。前五个以 C++23 模块使用同版本的 compat 实现：函数、类型、 枚举值以上游的全局名导出，常量宏与类型宏在 .macros 中为同名常量与别名，带参数的宏在 <mwrap/<lib>/macros.hpp>； 导出清单由各仓库的 tools/generate.py 按 clang 读到的头文件生成并在 CI 中审计。mcpplibs.mwrap.libc 映射 ISO C17 附录 B 的对象宏（stdout()、errno()、EOF、INT_MAX 等），实现为目标的 C 库。消费者测试 tests/mwrap/zlib-compress、 zstd-squeeze、xz-pack、xxhash-digest、libarchive-bundle、libc-stdio，以及已安装模板与重定位许可检查（检查脚本以 STATIC_NOTICES 表统一六个包的约定）。GLOBAL 为 GitHub 发布资产，CN 为 GitCode mcpp-res/mwrap-<lib> 镜像，sha256 两处一致。docs/mwrap.md 补充 C 标准库这一实现来源。

  • openkal-macos 0.22.1. The confinement rules are sized to the grants of each start; sixteen grants named near MAXPATHLEN no longer refuse a well-formed start with kal_err_invalid. OpenKal is the compatible range ^0.24.0. First member of the openkal 0.24.1 correction group (mcpp design record 2026-11-07 §4.2.3).

  • The openkal test members consume the 0.24 group. openkal-tests names openkal 0.24.0, Linux 0.25.0, macOS 0.22.1, Windows 0.20.0, LLVM runtime 0.19.0 and Emscripten 0.13.0; the platform, musl, tools and binding members name openkal-platform 0.24.0, openkal-musl 0.28.0 and the 0.5.0 image family. Under the 0.23 pins a 0.24 candidate could not share a build with the member.

  • openkal-musl 0.27.7. Select public Linux 0.24.2 and image loader 0.4.5 without changing the C library implementation or ABI. All ten producer jobs pass; matching source mirrors are verified and the direct consumer follows the release.

  • openkal-image source family 0.4.5. Loader, runner, tools and binding share the verified archive. The runner adopts Linux 0.24.2 unit-memory observation; okprof forwards complete environment values and child status. Both source consumers follow the release; hosted prebuilt tools and final engine qualification remain separate.

  • openkal-linux 0.24.2: avoid reading unrelated process RSS during unit memory observation; preserve refused-query fallback, group charges and supervision cadence.

  • openkal-platform 0.23.7. Image and hosted layers select musl 0.27.6 and LLVM runtime 0.18.7 consistently with the exact version group. The C library avoids redundant resolved-name property preflights; TLS, ThinLTO, loader, backend and hardening contracts remain intact. All four producer hosts passed; the hosted platform consumer follows the release. Final clangd cold CPU qualification remains separate.

  • openkal-llvm-runtime 0.18.7. Both allocator arrangements select musl 0.27.6; the C++ runtime implementation is unchanged. All ten producer checks passed, including native/cross-target behavior, four-host images and the unchanged L2 workload thresholds. GLOBAL and CN source archives are verified before registration; the conditional runtime test member follows the release.

  • openkal-musl 0.27.6. Resolve names through the optional operation without a redundant directory-property query, preserving weak-entry and unsupported fallbacks, lexical handling, errors and output bounds. All ten producer checks passed, including native compatibility controls and the same images on four hosts. GLOBAL and CN archives have the same verified SHA256; the direct C-library test member follows the release. Final clangd cold CPU qualification remains separate.

  • openkal-platform 0.23.5. Image layers and the version group select musl 0.27.5 and LLVM runtime 0.18.6 for scoped routing scratch. The loader, tools, backends and hardening selections are retained. All four producer hosts passed; the hosted platform test member follows the release.

  • openkal-llvm-runtime 0.18.6. Both allocator arrangements select musl 0.27.5 for scoped routing scratch with image automatic zeroing retained. The C++ runtime implementation is unchanged. All ten producer checks passed; the openkal test member follows the release. GLOBAL and CN source archives have the same verified SHA256.

  • openkal-musl 0.27.5. Scope routing scratch to the syscalls that use it and avoid large temporary initialization on empty descriptor unlocks and ordinary null-name rejections, while retaining image automatic zeroing and existing refusal/ownership behavior. All ten producer checks passed, including the same regression image on four hosts. GLOBAL and CN source archives have the same verified SHA256; the direct C-library test member follows the release.

  • openkal-platform 0.23.4. Both image and hosted arrangements select loader/tools 0.4.4, musl 0.27.4 and llvm-runtime 0.18.5. Kernel backend pins and compile/link conventions are unchanged. The hosted platform test member follows the release; mcpp remains 2026.11.3.1. GLOBAL and CN source archives have the same verified SHA256.

  • openkal-llvm-runtime 0.18.5. Both allocator arrangements select openkal-musl 0.27.4, which propagates image loader 0.4.4. The C++ runtime implementation is unchanged. The openkal test member follows the release. GLOBAL and CN source archives have the same verified SHA256.

  • openkal-musl 0.27.4. The image dependency selects openkal-ld 0.4.4 for the partial mapping correction. The C library implementation and hosted kernel backend pins are unchanged. The Linux test member follows the release. GLOBAL and CN source archives have the same verified SHA256.

  • openkal-ld, openkal-run, openkal-tools and openkal-bind 0.4.4. A refused later mapping run is copied without overwriting earlier read-only views; copied instructions are published separately. The correction passed four-host execution and the original Windows clangd startup and semantic replays. GLOBAL and CN source archives have the same verified SHA256.

  • mcpplibs.os 0.2.9. Linux selects openkal-linux 0.24.1 for corrected read-only confinement, and hosted/image qualification uses platform 0.23.3. The C++ API and implementation are unchanged. The os test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • openkal-platform 0.23.3. Both image and hosted arrangements select the corrected Linux confinement graph: Linux 0.24.1, musl 0.27.3, llvm-runtime 0.18.4 and image 0.4.3. It requires mcpp 2026.11.3.1. GLOBAL and CN archives have the same verified SHA256.

  • openkal-llvm-runtime 0.18.4. Both allocator arrangements select openkal-musl 0.27.3, which propagates Linux 0.24.1 and image loader 0.4.3. The C++ runtime implementation is unchanged. The openkal test member follows the release for musl targets. GLOBAL and CN archives have the same verified SHA256.

  • openkal-musl 0.27.3. The Linux dependency selects openkal-linux 0.24.1 for correct read-only confinement, and the image dependency selects openkal-ld 0.4.3. The C library implementation is unchanged. The Linux test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • openkal-ld, openkal-run, openkal-tools and openkal-bind 0.4.3. The native Linux runner uses openkal-linux 0.24.1, which requires Landlock ABI 3 before claiming read-only confinement. Both image test members follow the release. All four packages share one source archive; GLOBAL and CN downloads have the same verified SHA256.

  • openkal-linux 0.24.1. Read-only confinement requires Landlock ABI 3, which can restrict file truncation; earlier ABIs refuse a confinement request. The ABI probe cache uses atomic accesses. The openkal test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • mcpplibs.os 0.2.8. Process options expose granted directories and rights, confinement requests, resource preferences and the system null device. The corrected platform 0.23.2 group is verified on native, hosted and four image hosts. The os test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • openkal-platform 0.23.2. The corrected version group pins musl 0.27.2, llvm-runtime 0.18.3 and image tools 0.4.2; the published musl image edge now selects the same loader. It requires mcpp 2026.11.3.1. GLOBAL and CN archives have the same verified SHA256. The older published groups remain unchanged.

  • openkal-llvm-runtime 0.18.3. The runtime pins openkal-musl 0.27.2, whose image loader edge selects openkal-ld 0.4.2. The openkal test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • openkal-musl 0.27.2. The image dependency selects openkal-ld 0.4.2, matching the platform version group. The Linux test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • openkal-platform 0.23.1. This release supersedes 0.23.0 and pins openkal-macos 0.21.3, openkal-musl 0.27.1, openkal-llvm-runtime 0.18.2 and openkal-image 0.4.2. It requires mcpp 2026.11.2.3. GLOBAL and CN archives have the same verified SHA256.

  • openkal-llvm-runtime 0.18.2. The runtime pins openkal-musl 0.27.1 over openkal-macos 0.21.3, so hosted macOS programs receive their granted directories. The openkal test member follows the release. GLOBAL and CN archives have the same verified SHA256.

  • openkal-musl 0.27.1。 在 openkal-macos 0.21.3 之上：macOS 上的 hosted 程序得到被授予的目录（本库的初始化函数先于实现的运行， 实现改为从加载器的记录作答）。跨链接探针期望实现新导入的三个加载器名字；本库代码不变。测试成员 openkal-musl 随之移动。 GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.4.2。 在 openkal-macos 0.21.3 上构建 macOS 的运行器。测试成员 openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-macos 0.21.3。 在实现自己的初始化函数运行之前被提问时（链接在它之前的初始化函数，如 hosted 安排中 openkal-musl 的）， 参数、环境与启动者授予的目录取自加载器的记录（_NSGetArgc、_NSGetArgv、_NSGetEnviron）；此前被授予目录的 hosted 程序读到 实现的默认目录（整个文件系统、可写）。测试成员 openkal 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像， sha256 两处一致。

  • openkal-platform 0.23.0。 openkal 0.23 的版本组（openkal-linux 0.24.0、openkal-macos 0.21.2、openkal-windows 0.19.0、 openkal-musl 0.27.0、openkal-llvm-runtime 0.18.1、openkal-image 0.4.1）：映像在其基址上封存，运行器把它移到每次开机的基址并可从 初始化快照启动；每个单元以帧指针、全局栈保护、零初始化局部变量、libc++ 快速加固、CET（x86_64）或 pac-ret 与 BTI（aarch64） 编译，映像以 build-id 命名；okprof 列入平台工具；打包声明 gzip 时 okb 的映像压缩存放。要求 mcpp 2026.11.2.3（std 模块以平台的 选项编译）。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-llvm-runtime 0.18.1。 有分支保护时 compiler-rt 的 outline atomics 也能汇编（openkal-platform 0.23.0 在 aarch64 上的 -mbranch-protection=pac-ret+bti）：libunwind 的同名 assembly.h 不再跟在 compiler-rt 的之后重定义 GNU_PROPERTY，目标文件带有 aarch64 feature: BTI, PAC。测试成员 openkal 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-llvm-runtime 0.18.0。 建在 openkal-musl 0.27.0 之上（openkal 0.23），即 openkal-platform 0.23.0 所指的 C 库；加固与帧指针 随平台的编译选项。测试成员 openkal 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-musl 0.27.0。 面向 openkal 0.23（openkal-linux 0.24.0、openkal-macos 0.21.2、openkal-windows 0.19.0）与 openkal-image 0.4.1：各系统上的 /dev/null 交给启动的程序为环境的空设备；realpath 由环境回答；映像的 dlopen 放在其基址； 初始化快照的两阶段（__okrun_snapshot、__okrun_snapshot_start）；posix_spawn 把程序持有的目录连同权限授予启动的程序； okm_preopen_attenuate（<okm_preopen.h>）按程序自己的请求衰减持有的目录（含记录）；卷下的名字按环境的规则比较（盘符大小写、 两种分隔符）；mimalloc 的归还延迟随资源偏好。测试成员 openkal-musl 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.4.1。 在 openkal-macos 0.21.2 上构建 macOS 的运行器：睡眠挂起当前上下文而不再自旋，单调时钟粒度 每次启动相同，初始化快照不再因测得的差异被拒绝。测试成员 openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档， CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-macos 0.21.2。 单调时钟的粒度取内核的计时单位（mach_timebase_info，向上取整：arm64 为 42 ns，x86_64 为 1 ns）， 每次启动相同；此前以读数变化的差值测得，各次启动不同，openkal-image 的运行器在使用初始化快照前比较实现的事实，曾因此拒绝快照。 测试成员 openkal 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-macos 0.21.1。 睡眠不再占用处理器时间：内核读取 ulock_wait 所等待的字时不处理缺页，对尚未驻留的页返回 EFAULT；kal_time_sleep 等待的是一个从未写过的零字，每次等待立即失败，睡眠成了整段时长的自旋（在 arm64 与 x86_64 运行机上 睡 200 ms 耗费 127 至 200 ms 处理器时间）。等待现在在 EFAULT 时读取该字后重试，睡眠所用的字位于当前上下文的栈上。测试成员 openkal 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.4.0。 在 openkal 0.23 的实现上构建（openkal-linux 0.24.0、openkal-macos 0.21.0、openkal-windows 0.19.0）：映像在每次开机选定的基址上放置，数据作为预备副本保存在用户缓存中；触页记录（okprof record --what touch、 okld touch）按程序的资源偏好预读；初始化代码的快照每次开机生成一次、之后的启动直接映射（OKRUN_SNAPSHOT=0 关闭）；启动的 花费随资源偏好（performance、balanced、economy）变化，okrun cache 列出并回收运行器的缓存；okld bundle --compress 写出压缩 的 okb（okb 2）；okprof 成为 openkal-tools 的第三个程序。测试成员 openkal-tools（构建 okprof）、openkal-bind 随之移动。 GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal 0.23.0；openkal-linux 0.24.0、openkal-macos 0.21.0、openkal-windows 0.19.0、openkal-emscripten 0.12.0。 映像在其基址上放置（kal_exec_alloc_at、placement note）；exec 区域返回时为零，可封存（kal_exec_seal_part）、预取、私有映射 文件的部分（KAL_EXEC_MAP_WRITE）；按名字解析全部链接（kal_fs_resolved_name）与带属性的列举；目录授予的衰减（只读、不变、 记录）与系统隔离（KAL_SPAWN_CONFINE）；缺页、故障报告、采样与触页记录；资源偏好（kal_env_resources、 KAL_SPAWN_RESOURCES_*）与可用内存（kal_memory_info）。测试成员 openkal 随之移动，并观察基址上的区域、只读衰减、内存与 资源偏好。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.3.2。 在 openkal 0.22 的实现上构建（openkal-linux 0.23.0、openkal-macos 0.20.0、openkal-windows 0.18.0）：映像启动程序时可以在位置上得到系统的空设备（KAL_SPAWN_NULL_*），自身无改动。测试成员 openkal-tools、 openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal 0.22.0；openkal-linux 0.23.0、openkal-macos 0.20.0、openkal-windows 0.18.0、openkal-emscripten 0.11.0。 openkal.process 的位置上的空设备：KAL_SPAWN_NULL_IN、_OUT、_ERR 使启动的程序在该位置读到输入结束、写入全部被接受并 丢弃（属性 KAL_PROCESS_PROP_NULL_STREAMS）；Linux、macOS 在启动的程序一侧打开 /dev/null，Windows 为本次启动打开 NUL。 openkal-emscripten 依 0.22 编写，无其他改动。测试成员 openkal 随之移动，并观察标志与流同处一个位置时被拒绝。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.21.1。 版本组改为 openkal-image 0.3.1（记住的 okb 准入不再读取成员）、openkal-musl 0.26.1、 openkal-llvm-runtime 0.17.1，carrier 为 openkal-run 0.3.1；其余与 0.21.0 相同。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-llvm-runtime 0.17.1。 建在 openkal-musl 0.26.1 上（openkal-platform 0.21.1 的版本组）；L2 的系统一侧改由 Clang 编译， 使比较的是运行时而不是编译器。测试成员 openkal 随之移动。

  • openkal-musl 0.26.1。 映像的加载器为 openkal-ld 0.3.1（openkal-platform 0.21.1 的版本组），其余不变。测试成员 openkal-musl 随之移动。

  • openkal-ld/run/tools/bind 0.3.1。 记住的 okb 准入不再读取成员：okrun 对此前在同一文件上比对过的成员只按形状准入 （okld_okb_admit_layout：存储方式、在归档内、对齐），0.2.0 与 0.3.0 在这里计算归档声明的 CRC-32，每次启动遍历整个成员 （clangd 的 71 MB 映像约 0.1 s 处理器时间）。测试成员 openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档， CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • mcpplibs.os 0.2.7。 openkal 0.21 的实现（openkal-linux 0.22.0、openkal-macos 0.19.0、openkal-windows 0.17.0、openkal-emscripten 0.10.0），接口不变；其上的 ok 映像选 openkal-platform 0.21.0。测试成员 os 随之移动。

  • openkal-platform 0.21.0；openkal-emscripten 0.10.0。 openkal 0.21 的版本组：openkal 0.21.0 与三个实现、openkal-musl 0.26.0、 openkal-llvm-runtime 0.17.0、openkal-ld/run/tools 0.3.0；mcpp 2026.11.2.2 以它为内置的 <arch>-openkal 平台。openkal-emscripten 0.10.0 按 openkal 0.21 编写，0.21 的增补都在它不提供的接口上，其余不变。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像， sha256 两处一致。

  • openkal-musl 0.26.0、openkal-llvm-runtime 0.17.0。 openkal-musl 的分配器为嵌入的 mimalloc 3.6.1（malloc-mimalloc，默认； malloc-mallocng 保留 musl 自己的），匿名内存建在 openkal.region 上，定位读写不持锁，八个字符串函数按向量处理，普通互斥锁按 glibc 的方式等待。openkal-llvm-runtime 建在其上（裸机选 mallocng），PE 与 Mach-O 上 thread_local 的析构读到自己的变量 （emutls 在最后一轮才释放），并带 L2 的工作负载对比（bench/）。测试成员 openkal-musl、openkal 随之移动。CI 的 mcpp 移到 2026.11.2.1：openkal-musl 0.26.0 以 embed 嵌入 compat.mimalloc，并陈述 mcpp >= 2026.11。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • mcpplibs.mwrap.mimalloc 3.6.1（新包）。 mimalloc-m：以 C++23 模块（import mcpplibs.mwrap.mimalloc;）使用 compat.mimalloc 3.6.1。<mimalloc.h> 的函数、堆、arena、子进程、选项与 STL 分配器以上游的全局名导出；.stats、.profile 两个子模块对应 <mimalloc-stats.h>、<mimalloc-profile.h>；上游的 static inline 辅助函数以同名适配在 mcpplibs::mwrap::mimalloc；值宏在 .macros 中为常量，带类型参数的宏与 mi_stats_t_decl 留在 <mwrap/mimalloc/macros.hpp>。消费者测试 tests/mwrap/mimalloc-heap 与已安装模板检查（allocate 模板与重定位后的许可文件）。GLOBAL 为 GitHub 发布资产，CN 为 GitCode mcpp-res/mwrap-mimalloc 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.3.0。 openkal 0.21 的一轮：okld 把不可写、文件与内存大小相同、与文件偏移模 64 KiB 同余且独占所在 粒度的段从映像文件映射（okld_host::map，即 kal_exec_map_part），其余段照旧复制；每个重定位须写入可写段，否则拒绝映像； okrun 在程序运行期间保持映像文件打开。测试成员 openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal 0.21.0；openkal-linux 0.22.0、openkal-macos 0.19.0、openkal-windows 0.17.0。 openkal.exec 的 kal_exec_map_part：可执行区域的一部分由文件的字节构成（只读，或只读且可执行，属性 KAL_EXEC_PROP_FILE），加载器据此映射映像的 指令与只读数据；结束的程序的处理器时间在句柄释放前可读。openkal-linux 以 CLONE_VM | CLONE_VFORK 启动程序、kal_alloc 按需 切分；openkal-windows 不提供文件部分。测试成员 openkal 随之移动，并观察可执行区域的文件部分。

  • openkal-ld/run/tools/bind 0.2.0。 openkal 0.20 的一轮：运行器提供加载器接口 openkal.prof 与 openkal.debug， okrun --prof=（OKRUN_PROF）度量一个映像的调用、计数器与阶段，okprof（openkal-tools）记录、汇总与比较报告； kal_debug_symbolize 由映像文件的符号表给出地址的名字；okb 的准入按用户记住，同一文件的后续启动不再重读整个 okb。测试成员 openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal 0.20.0；openkal-linux 0.21.0、openkal-macos 0.18.0、openkal-windows 0.16.0、openkal-emscripten 0.9.0。 按偏移的传输 （kal_fs_read_at／kal_fs_write_at，不用也不改位置）；程序与单元的内存用量（KAL_PINFO_MEMORY、kal_process_job_usage）与 单元的内存限额（kal_process_job_limit，HARD／SUPERVISED）；可选接口 openkal.region（保留、分段提交、归还与丢弃、整体释放）； 加载器提供的 openkal.prof／openkal.debug。测试成员 openkal 随之移动，并观察按偏移的传输、本程序的内存与区域。 GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • compat.mimalloc 3.6.1。 与 3.4.5 并存；同一份源文件列表同时写出两个版本的目录布局（3.6.1 分为 alloc/、arena/、 heap/、prim/、profile/、util/ 七个目录，新增 profile/ 三个单元），列表中某版本没有的名字在该版本下不选中任何文件。 按 c11 编译时补上 _DEFAULT_SOURCE（上游以 gnu11 编译；3.6.1 的 prim/prim.c 在 prim/unix/prim.c 声明它之前已包含头文件）。 测试成员 mimalloc 随之移动。openkal-musl 0.26 将它嵌入为默认分配器。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.20.2。 openkal-musl 0.25.0、openkal-llvm-runtime 0.16.15：线程一起分配，memcmp 与 strlen 按字或向量。 GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-musl 0.25.0；openkal-llvm-runtime 0.16.15。 有第二个线程后，每个线程保留它释放的小尺寸类槽（≤ 2032 B）， 不经 mallocng 的锁取回：ok 映像中一次 malloc+free 在 1／2／4 线程下由 38.5／194／521 ns 降为 31／41／61 ns；memcmp 每次比较 8 字节，strlen 每次 16 字节（x86_64 上 SSE2，其余按字）。单线程程序的行为不变。测试成员 openkal、 openkal-musl 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • mcpplibs.os 0.2.6。 openkal-macos 0.17.1；接口不变。其上的 ok 映像选 openkal-platform 0.20.1。测试成员 os 随之移动。 GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.20.1。 openkal-macos 0.17.1、openkal-musl 0.24.1、openkal-llvm-runtime 0.16.14、 openkal-ld/run/tools 0.1.9：macOS 上上下文的标识不再每次进入内核。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.1.9；openkal-musl 0.24.1；openkal-llvm-runtime 0.16.14。 openkal-macos 0.17.1 的一轮： macOS 上的 okrun 与 openkal-musl 建在它之上，上下文的标识不再每次进入内核；格式与加载器不变。测试成员 openkal、 openkal-musl、openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像， sha256 两处一致。

  • openkal-macos 0.17.1。 kal_task_current 从系统库为每个线程保存的记录读取线程的内核标识（pthread_threadid_np）， 不再每次调用都进入内核；值不变。openkal-musl 经它取得 errno、线程指针与 ok 映像的每个（模拟的）线程局部变量，一次 clangd --check 调用约 158 万次。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • mcpplibs.os 0.2.5。 openkal 0.19 的实现（openkal-linux 0.20.0、openkal-macos 0.17.0、openkal-windows 0.15.0、 openkal-emscripten 0.8.0）；接口不变。其上的 ok 映像选 openkal-platform 0.20.0。测试成员 os 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.20.0。 openkal 0.19 的版本组：openkal 0.19.0、openkal-linux 0.20.0、openkal-macos 0.17.0、 openkal-windows 0.15.0、openkal-musl 0.24.0、openkal-llvm-runtime 0.16.13、openkal-ld/run/tools 0.1.8。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld/run/tools/bind 0.1.8；openkal-musl 0.24.0；openkal-llvm-runtime 0.16.13。 openkal 0.19 的一轮： okb 为每个映像成员记录 1 MiB 分块的 SHA-256（files.<member>.chunks），okrun 在多个上下文上同时校验各块，okld bundle 写入、okld bundle check 两种摘要都校验；openkal-musl 的 getpid 为环境给出的标识，kill(pid, 0)、getsid、getpgid 经 kal_process_open_id 回答另一程序是否在运行，flock 与 F_OFD_SETLK[W] 取打开文件的锁（kal_fs_lock）， SCHED_OTHER/BATCH/IDLE 与 setpriority 为调用上下文的占用（kal_task_set_priority）；openkal-llvm-runtime 随之移动。 测试成员 openkal、openkal-musl、openkal-tools、openkal-bind 的版本随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal 0.19.0；openkal-linux 0.20.0、openkal-macos 0.17.0、openkal-windows 0.15.0、openkal-emscripten 0.8.0。 openkal.task 增加两项：kal_task_cores（程序可运行于其上的处理器的物理核数，0 为无法回答）与 kal_task_set_priority（调用者所在上下文对处理器的占用：DEFAULT、LOW、BACKGROUND，属性位 KAL_TASK_PROP_PRIORITY， 升回被拒绝为 kal_err_permission）；规范 §1.1 写明边界：下层的东西不向上穿透，实现之间只在规范留名的余地内不同，绕过 openkal 的使用者绑定它所绕到的东西。各实现：Linux 以 sysfs 拓扑与 SCHED_OTHER/BATCH/IDLE，macOS 以 hw.physicalcpu 与 QoS 类，Windows 以处理器核心关系与后台模式，Emscripten 两者都答"无法回答／不支持"。测试成员 openkal 随之移动， 并观察 0.19 的两项。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.19.2。 openkal 0.18 的版本组，openkal-ld/run/tools 0.1.7、openkal-musl 0.23.2、 openkal-llvm-runtime 0.16.12：Linux aarch64 上 okrun 在处理器表明有 SHA-256 指令时以其接纳映像。openkal 0.18.0 与三个 实现不变。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld、openkal-run、openkal-tools、openkal-bind 0.1.7；openkal-musl 0.23.2；openkal-llvm-runtime 0.16.12。 Linux aarch64 上，加载器在处理器的 ID_AA64ISAR0_EL1 表明有 SHA-256 指令时以其求摘要（Linux 自 4.11 起模拟对标识 寄存器的 mrs，先以 uname 读内核版本）；0.1.6 只在编译目标保证这些指令时使用（Apple arm64）。openkal-musl 钉 openkal-ld 0.1.7，openkal-llvm-runtime 随之移动，二者源码不变。测试成员 openkal、openkal-musl、openkal-tools、 openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.19.1。 openkal 0.18 的版本组，openkal-ld/run/tools 0.1.6、openkal-musl 0.23.1、 openkal-llvm-runtime 0.16.11：okrun 在映像装入后释放它运行的文件，加载器以处理器的 SHA-256 指令求摘要、每个段只写 一次。openkal 0.18.0 与三个实现不变。其 CI 以 mcpp 2026.10.31.3 测量（集合的 Windows 启动器建在 mcpp 自身 openkal 行的平台上）。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-ld、openkal-run、openkal-tools、openkal-bind 0.1.6；openkal-musl 0.23.1；openkal-llvm-runtime 0.16.11。 okrun 在映像装入后释放它运行的文件，并在加载器交回时释放每个被依赖映像的文件：映像只以其副本常驻，不再同时以文件常驻 （clangd.okb 约少 68 MiB）。加载器不保留指向所装入字节的指针（okld.h），以处理器的 SHA-256 指令求摘要（x86_64 的 SHA 扩展；__ARM_FEATURE_SHA2 下的 ARMv8 指令），每个段只写一次。openkal-musl 钉 openkal-ld 0.1.6，openkal-llvm-runtime 随之移动，二者源码不变。测试成员 openkal、openkal-musl、openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • mcpplibs.os 0.2.4。 按 openkal 0.18 的实现：openkal 0.18.0、openkal-linux 0.19.0、openkal-macos 0.16.0、 openkal-windows 0.14.0、openkal-emscripten 0.7.0。其上的 ok 映像选择 openkal-platform 0.19.0（mcpp 2026.10.31.2 的 openkal 行钉 0.18.0，其版本组为 openkal 0.17.1）。测试成员 os 随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-emscripten 0.7.0。 按 openkal 0.18.0 编写，提供的十二个接口不变；openkal.map 不提供（Emscripten 的文件 mmap 是复制，无法满足共享区域的语义），链接时缺席。mcpplibs.os 0.2.4 的 wasm32-emscripten 由此解析；测试成员 openkal 的 wasm32 行随之移动。GLOBAL 为 GitHub 标签归档，CN 为 GitCode mcpp-res 镜像，sha256 两处一致。

  • openkal-platform 0.19.0。 openkal 0.18 的版本组:openkal 0.18.0、openkal-linux 0.19.0、openkal-macos 0.16.0、 openkal-windows 0.14.0、openkal-musl 0.23.0、openkal-llvm-runtime 0.16.10、openkal-ld/run/tools 0.1.5。以 Windows 启动器打包(bundle-all、self-contained)需要 mcpp 2026.10.31.2。CI 的 mcpp 移到 2026.10.31.1(platform 0.18.0 起声明 mcpp >= 2026.10.30.1),客户端下限不变。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-musl 0.23.0、openkal-llvm-runtime 0.16.10。 openkal-musl 的文件 mmap、munmap、msync 经 openkal.map(偏移按 KAL_MAP_ALIGNMENT 向下对齐,区域止于文件末尾);openkal-llvm-runtime 随之移动。测试成员 openkal-musl 观察映射的文件,openkal 移到 0.16.10。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像, sha256 两处一致。

  • openkal-ld、openkal-run、openkal-tools、openkal-bind 0.1.5。 okrun 以 openkal.map(私有、可写)映射它运行的映像 或 okb,而不是整体读入内存,映像结束时释放;映像绑定 openkal.map 的三个函数。四个成员钉 openkal 0.18.0、 openkal-linux 0.19.0、openkal-macos 0.16.0、openkal-windows 0.14.0。测试成员 openkal-tools、openkal-bind 随之移动。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal 0.18.0、openkal-linux 0.19.0、openkal-macos 0.16.0、openkal-windows 0.14.0。 新的可选接口 openkal.map(KAL_IFACE_MAP):kal_map_file 把文件的一部分映射到地址空间(偏移为 KAL_MAP_ALIGNMENT,即 64 KiB 的倍数;读或写、私有或共享),kal_map_sync 使共享区域的写入对文件读取可见,kal_map_release 按地址与长度 释放。区域不越过文件末尾、不可执行;末页中文件末尾之后的字节读为零。三个实现分别以 mmap、mmap 与 section/view 实现。测试成员 openkal 随之移动,并观察 0.18 的映射。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像, sha256 两处一致。

  • mcpplibs.os 0.2.3。 钉 openkal-linux 0.18.3:目录句柄以 O_PATH 打开,进程可搜索而不可读的目录中按绝对名 启动的程序能被找到(Android 应用沙箱,mcpp-community/mcpp#857)。测试成员 os 随之移动。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-platform 0.18.0。 运行器声明 hosts(okrun 构建的系统与架构,即需要它的包能运行的地方);删除 universal(打包只含命令命名的腿);版本组为 openkal-linux 0.18.3、openkal-musl 0.22.9、openkal-llvm-runtime 0.16.9、openkal-ld/run/tools 0.1.4。需要 mcpp 2026.10.30.1;测试成员 openkal-platform 在本仓库 CI 的 mcpp 移到 2026.10.30.1 时随之移动。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-musl 0.22.9、openkal-llvm-runtime 0.16.9。 openkal-musl 的 pread、pwrite、preadv、pwritev 由定位、传输与恢复位置组成(此前返回 ENOSYS);openkal-llvm-runtime 在 ok 映像上导出 __cxa_thread_atexit, 带析构的 thread_local 的映像可以封装。测试成员 openkal、openkal-musl 随之移动。GLOBAL 为 GitHub 标签归档, CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-musl 0.22.8、openkal-llvm-runtime 0.16.8。 openkal-musl 钉 openkal-ld 0.1.4(本轮 openkal-image 归档); 0.22.7 仍钉 0.1.3,与本轮平台的版本组不一致。openkal-llvm-runtime 随之移动。测试成员 openkal、openkal-musl 随之移动。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-musl 0.22.7、openkal-llvm-runtime 0.16.7、openkal-ld / openkal-run / openkal-tools / openkal-bind 0.1.4。 openkal-musl 钉 openkal-linux 0.18.3,并只在内部 overlay 在命令行上时为 C++ 定义 restrict:musl 的公开头写 __restrict,而为每个 C++ 消费者定义的宏占用了程序自己的名字(clang 的 TokenKinds.def 把 restrict 作为宏 实参传入)。openkal-llvm-runtime 随之移动;openkal-image 的四个成员钉 openkal-linux 0.18.3,okrun 与载体能在 可搜索不可读的目录中启动程序。测试成员 openkal、openkal-musl、openkal-tools、openkal-bind 随之移动。 GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-linux 0.18.3。 每个 kal_dir(含两个预开放目录)以 O_PATH 打开:在其下解析名字、在其中启动程序、 描述它都不需要读权限,列举时另开可读的描述符。Android 应用沙箱(run-as,SELinux runas_app)中根目录的预开放以 EACCES 失败,以绝对名启动的每个程序报告为找不到(mcpp-community/mcpp#857)。测试成员 openkal 移到 0.18.3。 GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • mcpplibs.mwrap.libvpx 1.17.0(新包)。 libvpx-m:以 C++23 模块(import mcpplibs.mwrap.libvpx;)使用 VP9 编解码库 libvpx 1.17.0 与 WebM 容器库 libwebm 1.0.0.32(建立在 compat.libvpx 与 compat.libwebm 之上)。根模块导出 libvpx 头文件的 133 个类型、192 个枚举值、上游导出的 35 个函数与两个 VP9 接口(VP8 未构建,其接口不导出),头文件中 86 个类型化控制函数 (VPX_CTRL_USE_TYPE 生成的 static 函数)在 mcpplibs::mwrap::libvpx 中同名适配;mcpplibs.mwrap.libvpx.webm 在各自 命名空间导出 libwebm 的 mkvmuxer、mkvparser 与 libwebm(命名空间作用域常量为内部链接,其值在 mcpplibs::mwrap::libvpx::mkvmuxer / ::mkvparser 下同名提供);mcpplibs.mwrap.libvpx.macros 把 74 个宏映射为常量、 函数与 constexpr 函数,其余(vpx_codec_control 等)留在 <mwrap/libvpx/macros.hpp>。描述符为 libvpx-m 的不可变 mwrap-1.17.0 发布包(暂无 CN 镜像)。新增使用者 tests/mwrap/libvpx-webm:经类型化控制编码 VP9、mkvmuxer 封装、 mkvparser 解析并解码(PSNR 下限)、两次封装字节相同,以及侧边头文件与 import 同时使用;validate.yml 新增已安装模板检查 (wrapper 的 LICENSE/NOTICE 与两个库的 README、LICENSE、PATENTS、AUTHORS 在搬迁后的发布包中逐字节一致)。

  • compat.libvpx 1.17.0(新包)。 libvpx:WebM 项目的 VP9 视频编解码器(编码器与解码器;BSD-3-Clause,附 WebM 项目的 免版税专利授权 PATENTS)。从 v1.17.0 标签归档构建上游 configure --target=generic-gnu --disable-vp8 --enable-vp9 --enable-multithread(不含示例、工具、文档、单元测试、webm-io、libyuv)所编译的 101 个 C 源文件:通用 C 实现,无 SIMD、 无汇编、无运行时 CPU 检测,同一配置在 x86-64 与 aarch64、Linux、macOS、Windows 与 wasm32-emscripten 上不变地构建。 该配置生成的 vpx_config.h、vpx_config.c、vpx_version.h 与三个 RTCD 头(vp9_rtcd.h、vpx_dsp_rtcd.h、 vpx_scale_rtcd.h)作为 generated_files 原样提供(私有头目录),只有描述宿主操作系统的三行改由预处理器决定: Windows 以外有 pthread.h、unistd.h(Windows 上 vpx_util/vpx_pthread.h 用 Win32 实现工作线程),glibc 与 Apple 上有 pthread_setname_np;不带 pthreads 的 Emscripten 上 CONFIG_MULTITHREAD 为 0(单线程工作器依次执行各块)。 -ffp-contract=off。使用者 #include <vpx/vpx_encoder.h>、<vpx/vp8cx.h> 等(上游安装布局)。url 为上游标签归档 (暂无 CN 镜像);声明 extensions.autoupdate。新增测试成员 tests/examples/libvpx:版本与构建配置字符串、 一遍编码(好质量、恒定质量)解码回来的 PSNR、实时速度 8、无损逐像素还原、单线程两次编码字节相同、四线程分块编码 两线程解码。

  • compat.libwebm 1.0.0.32(新包)。 libwebm:WebM 项目的 WebM(Matroska)容器库,复用器 mkvmuxer 与解析器 mkvparser (BSD-3-Clause)。从 libwebm-1.0.0.32 标签归档构建上游 CMakeLists.txt 的 webm 目标:common/file_util.cc、 common/hdr_util.cc 与 mkvmuxer、mkvparser 的源文件(不含默认关闭的新解析器 webm_parser/、MPEG-TS 工具、WebVTT 与示例程序);无配置头、无生成文件。使用者 #include <mkvmuxer/mkvmuxer.h>、<mkvparser/mkvparser.h> 等。新增测试 成员 tests/examples/libwebm:写一个 VP9 与 Opus 两条轨道的 WebM(BT.709 有限范围的色彩、OpusHead、编码延迟、 关键帧、cues、时长)到内存与磁盘(逐字节相同),用 mkvparser 从内存与 MkvReader 读回每一帧的字节与时间;给定轨道 UID 时两次复用字节相同(不给时 mkvmuxer 按当前时间随机生成)。

  • mcpplibs.mwrap.libwebp 1.5.0(新包)。 libwebp-m:以 C++23 模块(import mcpplibs.mwrap.libwebp;)使用 compat.libwebp 1.5.0(BSD-3-Clause 与 Google 专利授权)。从固定版本的公开头文件生成,以 export using 导出:根模块 webp/types.h、decode.h、encode.h、mux_types.h 的 23 个类型、59 个枚举值与 72 个函数,mcpplibs.mwrap.libwebp.sharpyuv (根模块重新导出),以及 demux/mux 特性下的 mcpplibs.mwrap.libwebp.demux(WebPDemux*、WebPAnimDecoder*)与 mcpplibs.mwrap.libwebp.mux(WebPMux*、WebPAnimEncoder*),特性转发到 compat.libwebp 的同名特性。22 个 static inline 函数(WebPConfigInit、WebPPictureInit、WebPGetFeatures、WebPAnimEncoderNew…)在 mcpplibs::mwrap::libwebp 中以同名同签名适配;mcpplibs.mwrap.libwebp.macros 映射 ABI 版本、WEBP_MAX_DIMENSION、 sharpyuv 版本与 WEBP_ABI_IS_INCOMPATIBLE/SHARPYUV_MAKE_VERSION。包装仓库 CI(Linux x86_64 GCC/LLVM、Linux arm64 GCC、 macOS、Windows、wasm32-emscripten,dev 与 release)固定编码字节与解码像素的哈希,在所有目标上一致;一致性检查确认 examples/webpcodec 的编码与解码结果与上游 makefile.unix 构建的 cwebp/dwebp 逐字节相同(76 项)。描述文件 pkgs/mwrap/libwebp.lua 指向不可变的 mwrap-1.5.0 发布归档(暂无 CN 镜像)。新增测试成员 tests/mwrap/libwebp-image (开启 demux 与 mux:有损与无损 RGBA 往返含 alpha、高级 API 及固定哈希、动画逐帧编码与回放、错误路径),validate.yml 中 验证已安装归档的默认 image 模板及其迁移后的许可文件。

  • mcpplibs.mwrap.pocketpy 2.2.0(新包)。 pocketpy-m:以 C++23 模块(import mcpplibs.mwrap.pocketpy;)使用 compat.pocketpy 2.2.0(MIT)。从固定版本的 <pocketpy.h> 生成,以 export using 导出全部 29 个类型、91 个枚举值与 246 个函数(上游全局名不变);mcpplibs.mwrap.pocketpy.macros 把 82 个宏中的 65 个映射为常量与函数(PK_VERSION、 PK_ENABLE_*、py_isint…、py_r0…、TypeError 等为传给 py_exception 的可变参数模板,py_callcfunc 两种 NDEBUG 状态各自正确),PY_CHECK_ARGC、PY_CHECK_ARG_TYPE、py_arg 留在 <mwrap/pocketpy/macros.hpp>。包装仓库 CI (Linux x86_64 GCC/LLVM、Linux arm64 GCC、macOS、Windows、wasm32-emscripten,dev 与 release)运行嵌入 API 测试,并在 只用本模块写成的宿主上运行上游全部 92 个 tests/*.py(源码与编译成 .pyc 各一遍)。描述文件 pkgs/mwrap/pocketpy.lua 指向不可变的 mwrap-2.2.0 发布归档(暂无 CN 镜像)。新增测试成员 tests/mwrap/pocketpy-embed (exec/eval 读回、遍历 dict、Python 调用 C 函数、错误消息与 VM 继续、同一 VM 中重复执行、watchdog,以及侧头文件与 导入并用),validate.yml 中验证已安装归档的默认 script 模板及其迁移后的许可文件。

  • compat.pocketpy 2.2.0(新包)。 PocketPy 2:用 C11 写的小型可嵌入 Python 3.x 解释器(MIT,无依赖)。从标签归档 构建 src/**/*.c(即上游 CMake 的 POCKETPY_SRC;_generated.c 已随源码提供,无需 prebuild.py)为静态库, 按上游 CMake 的默认做法作为一个 unity 翻译单元编译(生成的 pocketpy_unity.c 按 CMake 的 GLOB_RECURSE 顺序包含 84 个 源文件;源码依赖于此:NDEBUG 下 PK_INLINE 把头文件声明、其他文件调用的函数标为 inline,clang 在 MSVC ABI 下不输出 其定义,逐个编译会在 Windows 上留下未定义符号),-std=gnu11。配置取 pocketpy/config.h 给未定义任何宏的使用者 的取值(即使用者的 <pocketpy.h> 所见):PK_ENABLE_OS=1、PK_ENABLE_THREADS=0(CMake 打开它只在其 unity 构建下 能编译:time.c 未包含声明 c11_thrd__yield 的头文件)、PK_ENABLE_DLL=0;另打开两项上游选项: PK_ENABLE_DETERMINISM=1 与 -ffp-contract=off(同 CMake,浮点结果跨平台一致)、PK_ENABLE_WATCHDOG=1 (py_watchdog_begin/py_watchdog_end 在头文件中总是声明,只在打开时才有定义)。NDEBUG 随构建配置(release 定义),库与使用者一致。install() 带匹配计数地应用上游 2.2.0 之后的修复 de8351ed:异常对象记录的回溯帧中只有 调试器才填写的 locals/globals 未初始化,而垃圾回收无条件标记它们,异常对象存活时回收会读到未初始化内存并可能崩溃 (上游自己的 tests/901_array2d_extra1.py 按 build.sh 构建即崩溃);修复将二者置为 nil。Linux 链接 -lm,Windows 链接 ws2_32 并定义 _CRT_SECURE_NO_WARNINGS。Linux、macOS、 Windows 与 wasm32-emscripten 使用同一组源文件与参数。使用者 #include <pocketpy.h>。url 为上游标签归档(暂无 CN 镜像);声明 extensions.autoupdate(v${version} 标签)。新增测试成员 tests/examples/pocketpy:版本与配置、 exec/eval 与 int/float/str/bool 读回、dict 与 list 的遍历、绑定的 C 函数及其参数检查、语法错误/运行时错误/ 抛出/无限递归均返回 false 并带消息且 VM 可继续、异常对象跨多次垃圾回收存活、watchdog 结束死循环、json/math/collections、确定性浮点值、 同一 VM 中重复执行、第二个 VM 与 py_resetvm。

  • mcpplibs.os 0.2.2。 新增 wasm32-emscripten 目标:基于 Emscripten 的 C 库与 openkal-emscripten 0.6.0 的 wasm 模块,在 node 或页面中运行;新增 platform::emscripten、architecture::wasm32 与 is_emscripten,不定义平台模块。 openkal-emscripten 没有 openkal.process,启动程序的调用在链接时失败并给出 openkal 符号名;interrupt 报告不会收到 结束请求。修正(所有目标):fs::read 不再经栈上 64 KiB 数组读取(它占满了 wasm 模块的默认栈);stamp_of 与 identity_of 同时请求节点种类,不再把已有文件报告为不存在。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res/os 镜像,sha256 一致。测试成员 os 移到 0.2.2。

  • mcpplibs.openkal-emscripten 0.6.0。 按 openkal 0.17.1 实现其提供的十二个接口,使依赖 openkal 0.17 的 mcpplibs.os 能在 wasm32-emscripten 上解析与链接。kal_env_image 为 node 所给的脚本(页面中为 kal_err_not_found), kal_env_loader 为 kal_err_not_found,kal_env_system 为 emscripten;kal_fs_rename_flags 中 KAL_RENAME_NO_REPLACE 为 kal_err_not_supported(C 库没有不替换的原子改名),声明 KAL_FS_PROP_REMOVE_OPEN (在 MEMFS 上测得);kal_net_listen_at/kal_net_connect_at 为 kal_err_not_supported。修正:C 库对其自身终端设备 即使在管道下也回答 isatty 为 1,现在由宿主(node 的 tty.isatty)判断标准流是否为终端,终端设置 KAL_TERM_SEQUENCES。一致性(emsdk 6.0.9、node 26.7.0):终端下 109 成立、0 不成立、14 未观察;管道下 97、0、15。 GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res/openkal-emscripten 镜像,sha256 一致。测试成员 openkal 的 wasm32 依赖移到 0.6.0。

  • mcpplibs.os 0.2.1。 在程序自己的 C 库的两种安排下构建并通过测试:系统自己的 C 库,以及位于系统自身三元组上的 openkal-musl 与 openkal-llvm-runtime(mcpp docs/24)。机器、内存、卷的种类与两项交换在 Linux 与 macOS 上经内核调用 得到,Windows 上以 32 位 DWORD 与 UTF-16 WCHAR 声明 kernel32 的名字,均不经 C 库;标准输出的转向与 SIGPIPE 在进程 保存它们的地方修改。mcpp-language-server 的操作系统层进入 os(有界运行、线程、环境赋值、有界读取、规范名)。 ok image 的 C 库、C++ 运行时与加载器取自其平台(openkal-platform,mcpp 2026.10.27.1 为 <arch>-openkal 选择), 包不再声明它们。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res/os 镜像,sha256 一致。测试成员 os 移到 0.2.1。

  • mcpplibs.mwrap.dr_libs 2026.03.03(新包)。 dr_libs-m:以 C++23 模块(import mcpplibs.mwrap.dr_libs;)使用 compat.dr_libs 2026.03.03(dr_wav 0.14.5、dr_flac 0.13.3、dr_mp3 0.7.3)。每个头文件各一个模块且可单独导入: mcpplibs.mwrap.dr_libs.wav(42 个类型、48 个枚举值、94 个函数)、.flac(32、6、31)、.mp3(28、8、29),全部以 export using 导出上游全局名;每个枚举都由 typedef 命名,枚举值按原样导出。mcpplibs.mwrap.dr_libs.macros 把 171 个 对象式宏映射为其自身类型的常量;*_API 等属性、字符串化宏与 dr_flac 的平台检测宏共 28 个留在 <mwrap/dr_libs/macros.hpp>。包装仓库的 CI(Linux x86_64 GCC/LLVM、Linux arm64、macOS、Windows)逐样本核对 FLAC 解码、按 LAME 标签的无缝长度解码 MP3、在各容器中往返 WAV,并与 compat.miniaudio 链接在同一程序中解码出相同样本。 GLOBAL 为 mwrap-2026.03.03 发布资产,CN 为 GitCode mcpp-res/mwrap-dr_libs 镜像,sha256 一致。新增测试成员 tests/mwrap/dr_libs-audio 与已安装模板及其许可文件的部署检查。

  • compat.dr_libs 2026.03.03(新包)。 dr_libs:单文件的 WAV/AIFF、FLAC 与 MP3 解码器(以及 WAV 编码器),C 实现, 无依赖,许可为 MIT-0 或 Unlicense 二选一。上游按头文件分别打标签(wav-*、flac-*、mp3-*),没有同时覆盖三者的标签; 本包固定 wav-0.14.5 的提交 fa931f3(2026-03-03)的归档,其中 dr_flac.h、dr_mp3.h 与 flac-0.13.3、mp3-0.7.3 标签逐字节相同,即 dr_wav 0.14.5、dr_flac 0.13.3、dr_mp3 0.7.3 三者均为已发布版本的最新提交;版本号取提交日期(同 compat.nanosvg)。一个生成的实现编译单元同时定义 DR_WAV_IMPLEMENTATION、DR_FLAC_IMPLEMENTATION、 DR_MP3_IMPLEMENTATION,构建为一个静态库;使用者 #include <dr_wav.h>(<dr_flac.h>、<dr_mp3.h>)并链接,不要再定义 这些宏。上游默认配置(stdio 与转换接口保留,SIMD 由编译器预定义宏决定)。miniaudio 内嵌的是改名的副本(ma_dr_*), 两者可在同一程序中共存。GLOBAL 为 GitHub 提交归档,CN 为 GitCode mcpp-res/dr_libs 镜像,sha256 一致。新增测试成员 tests/examples/dr_libs(三平台):WAV(RIFF、Wave64、IEEE float、mu-law)往返、FLAC 按 STREAMINFO 的 MD5 逐样本无损解码与 定位、MP3 按 LAME 标签的无缝长度解码。

  • mcpplibs.mwrap.opus 1.6.1(新包)。 opus-m:以 C++23 模块(import mcpplibs.mwrap.opus;)使用 compat.opus 1.6.1、 compat.opusfile 0.12 与 compat.ogg 1.3.6。mcpplibs.mwrap.opus 导出 libopus 的 13 个类型与 87 个函数,并重新导出 .file(opusfile:10 个类型、54 个函数;不导出未构建的 libopusurl 的 9 个声明)、.ogg(libogg:12 个类型、71 个函数) 与 .macros(115 个整数常量、6 个类型别名、54 个 CTL 宏映射为返回带类型 ctl_request 的 constexpr 函数,7 个 *_ctl 函数各有接受它的重载,opus_encoder_ctl(enc, OPUS_SET_BITRATE(64000)) 写法不变);属性、版本测试与 CTL 参数检查等 22 个宏留在 <mwrap/opus/macros.hpp>。包装仓库的 CI(Linux x86_64 GCC/LLVM、Linux arm64、macOS、Windows)经由模块 解码 RFC 8251 的 12 个测试向量(5 种采样率、单声道与立体声,共 120 次,逐包核对区间解码器最终状态,并以 libopus 的 opus_compare 对照参考输出),0 失败;212 个导出函数全部可链接。GLOBAL 为 mwrap-1.6.1 发布资产,CN 为 GitCode mcpp-res/mwrap-opus 镜像,sha256 一致。新增测试成员 tests/mwrap/opus-ogg 与已安装模板及其许可文件的部署检查。

  • compat.ogg 1.3.6、compat.opus 1.6.1、compat.opusfile 0.12(新包)。 Opus 音频的三个 Xiph.Org 库,均为 BSD-3-Clause,均以上游发布 tarball 从源码构建为静态库。compat.ogg:Ogg 容器的分页与位打包(src/framing.c、 src/bitwise.c),<ogg/config_types.h> 按上游 CMake 的结果由 generated_files 生成(int16_t…uint64_t)。 compat.opus:Opus 编解码器(RFC 6716)的编码器与解码器、multistream、ambisonics projection 与 repacketizer; 上游默认的浮点构建(源文件取自 celt_sources.mk / silk_sources.mk / opus_sources.mk),deep PLC、DRED、 OSCE 与 QEXT 关闭(上游默认),纯 C、不启用 SIMD 内建函数与运行时 CPU 检测(x86 内建函数需要逐文件 -m 标志); 生成的 config.h(OPUS_BUILD、PACKAGE_VERSION "1.6.1"、VAR_ARRAYS、ENABLE_HARDENING)与内部头文件目录 是私有包含目录,使用者只看到 include/(#include <opus.h>);Linux/macOS 以 -fvisibility=hidden 编译, 与上游 configure 一致。compat.opusfile:Ogg Opus 文件(RFC 7845)的解码与精确定位,依赖 compat.ogg 与 compat.opus;只构建 libopusfile(不含需要 OpenSSL 的 libopusurl / HTTP)。GLOBAL 为上游发布资产 (opus 为 downloads.xiph.org,GitHub 无 1.6.1 发布;ogg 与 opusfile 为 GitHub 发布资产),CN 为 GitCode mcpp-res/opus、mcpp-res/ogg、mcpp-res/opusfile 镜像,sha256 一致;声明 extensions.autoupdate(v${version} 标签)。新增测试成员 tests/examples/opus(三平台):CELT 与 SILK 往返(信噪比)、包解析、5.1 multistream、 ambisonics、repacketizer,以 libogg 生成的 Ogg Opus 流经 opusfile 读取(OpusHead、OpusTags、精确长度、定位)。

  • mcpplibs.mwrap.box2d 3.2.0(新包)。 box2d-m:以 C++23 模块(import mcpplibs.mwrap.box2d;)使用 compat.box2d 3.2.0。按上游全局名导出已安装头文件的 110 个类型、3 个不透明结构体、176 个枚举值、506 个 B2_API 函数、 91 个内联函数、8 个 C++ 向量运算符与 b2_lengthUnitsPerMeter;头文件的 13 个 static const 对象(内部链接)以同类型、 同初值的常量置于 mcpplibs::mwrap::box2d。mcpplibs.mwrap.box2d.macros 把 20 个宏映射为常量、5 个读取长度单位的宏 映射为函数(B2_LINEAR_SLOP())、3 个 id 宏映射为 constexpr 函数;声明说明符、初始化器语法与断言留在 <mwrap/box2d/macros.hpp>。包装仓库的 CI(Linux x86_64 GCC/LLVM、Linux arm64 GCC/LLVM、macOS、Windows、 wasm32-emscripten)在 dev 与 release 下运行确定性场景:上游的 falling hinges(第 299 步、哈希 0x465F3DF4)与 被撞倒的 20 层金字塔(600 步,哈希 0x790D7C28),1–8 个 worker、用户任务系统、SSE2 回退,各行逐位一致。 GLOBAL 为 mwrap-3.2.0 发布资产,CN 为 GitCode mcpp-res/mwrap-box2d 镜像,sha256 一致。新增测试成员 tests/mwrap/box2d-physics 与已安装模板及其许可文件的部署检查。

  • compat.box2d 3.2.0(新包)。 Box2D v3:游戏用 2D 刚体物理引擎(C17,MIT,无依赖)。按上游 CMake 的做法从标签归档 构建 src/*.c 为静态库:-std=gnu17、-ffp-contract=off(上游为跨平台确定性对每个 GCC/Clang 设置,禁止乘加收缩为 FMA)、上游默认的 SIMD 选择(x86_64 为 SSE2,并在运行时按 cpuid 分派 AVX2 求解器;arm64 为 Neon)、unix 上 -fPIC -fvisibility=hidden,Linux 链接 -lm -lpthread;Emscripten 目标加上游同样的 -msimd128 -msse2(target_cfg)。 不定义 BOX2D_VALIDATE / BOX2D_DOUBLE_PRECISION / BOX2D_PROFILE(与上游作为依赖使用时相同)。使用者 #include <box2d/box2d.h>。 GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致;声明 extensions.autoupdate(v${version} 标签)。 新增测试成员 tests/examples/box2d(三平台):版本、下落与休眠、接触与移动事件、射线与凸包,以及上游的确定性场景 falling hinges(第 299 步全部休眠、变换哈希 0x465F3DF4,1 个与 4 个 worker、SSE2 回退路径)。

  • mcpplibs.mwrap.miniaudio 0.11.25(新包)。 miniaudio-m:以 C++23 模块(import mcpplibs.mwrap.miniaudio;)使用 compat.miniaudio 0.11.25(MIT-0 或 Unlicense)。导出 miniaudio.h API 部分的全部 266 个类型与结构体标签、368 个枚举值与 931 个 MA_API 函数(上游全局名不变),每个声明位于头文件声明它的同一预处理条件下;三个 static MA_INLINE 辅助函数在 mcpplibs::mwrap::miniaudio 中适配;mcpplibs.mwrap.miniaudio.macros 把 27 个数值宏映射为常量,并把兼容名字 (ma_resource_manager_job*)映射为类型别名与函数引用;属性、字符串化与平台/后端测试宏留在 <mwrap/miniaudio/macros.hpp>。 包装仓库的 CI(Linux x86_64 GCC/LLVM、Linux arm64、macOS、Windows,以及 Web:wasm32-emscripten,node 下运行测试) 在每个目标上依编译器自身的预处理审计导出。GLOBAL 为 mwrap-0.11.25 发布资产,CN 为 GitCode mcpp-res/mwrap-miniaudio 镜像,sha256 一致。新增测试成员 tests/mwrap/miniaudio-engine 与已安装模板及其许可文件的部署检查。

  • mcpplibs.mwrap.sheenbidi 3.0.0(新包)。 sheenbidi-m:以 C++23 模块(import mcpplibs.mwrap.sheenbidi;) 使用 compat.sheenbidi 3.0.0。导出已安装头文件的全部类型、结构体标签与 51 个 SB_PUBLIC 函数(上游全局名不变); mcpplibs.mwrap.sheenbidi.macros 把宏映射为常量与 constexpr 函数,并把无名枚举的 236 个枚举值映射为其 typedef 类型的常量;SB_PUBLIC、SB_DEPRECATED 与 extern "C" 括号留在 <mwrap/sheenbidi/macros.hpp>。包装仓库的 CI (Linux x86_64 GCC/LLVM、Linux arm64、macOS、Windows)运行 Unicode 17.0.0 的 BidiTest.txt(770,241 例)与 BidiCharacterTest.txt(91,707 例),0 错误。GLOBAL 为 mwrap-3.0.0 发布资产,CN 为 GitCode mcpp-res/mwrap-sheenbidi 镜像,sha256 一致。新增测试成员 tests/mwrap/sheenbidi-bidi 与已安装模板及其许可文件的部署检查。

  • compat.sheenbidi 3.0.0(新包)。 SheenBidi:Unicode 双向算法(UAX #9)的 C 实现,Apache-2.0,无依赖; 3.0.0 实现 Unicode 17.0.0,通过该版本的 BidiTest.txt 与 BidiCharacterTest.txt 全部用例。以上游的单一编译单元 Source/SheenBidi.c(SB_CONFIG_UNITY)从源码构建为静态库,只导出公共头文件的 51 个 SB* 入口;使用者的包含路径 只有 Headers(#include <SheenBidi/SheenBidi.h>),内部头文件所在的 Source 是私有包含目录。未定义 SB_CONFIG_EXPERIMENTAL_TEXT_API(上游默认,实验性的 SBText 接口不编译)。是 compat.fribidi(LGPL-2.1-or-later) 的宽松许可替代,可静态链接。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致; 声明 extensions.autoupdate(v${version} 标签)。新增测试成员 tests/examples/sheenbidi(三平台)。

  • openlifa.openmui 0.3.0。 OpenLifa 标准 openmui 的规范:registry、C ABI(include/openmui.h, 在使用者的包含路径上)和声明其值类型的 C++ 模块 openmui.spec(语义树节点及其一致性检查、actor、 信封、Core 组件契约)。actor、效果、授权与信封采用 openas 0.2。只依赖标准库(头文件为 C99);代码 Apache-2.0,规范文本 CC BY-SA 4.0。GLOBAL 为 GitHub 标签归档。新增测试成员 tests/examples/openlifa.openmui。

  • openlifa.openas 0.2.0。 OpenLifa 标准 openas 的规范与声明它的 C++ 模块(openas、 openas.conformance):actor 及其委托链的文本形式、动词的效果等级、系统上限之下的授权与单个请求的决定、 运行信封的记录种类、退出码与错误码,以及动词描述、actor 与授权的一致性检查。只依赖标准库;代码 Apache-2.0, 规范文本 CC BY-SA 4.0。GLOBAL 为 GitHub 标签归档。新增测试成员 tests/examples/openlifa.openas。

  • gcc.libstdcxx 16.1.0.1。 向 llvm 构建提供 mcpp:c++-abi=libstdc++:安装时链接 xim:gcc 16.1.0 载荷的头文件与运行库目录并写出自身清单(std-module 为 bits/std.cc), clang 据此以 libstdc++ 编译、import std 与链接(需要 mcpp 2026.10.26.1,SPEC-002 §7)。 新增测试成员 tests/examples/libstdcxx-llvm。

  • openkal 0.17.1 及其实现 openkal-linux 0.18.1、openkal-macos 0.15.1、openkal-windows 0.13.1。 openkal 增加 KAL_SPAWN_ONE_STRING / KAL_PROCESS_PROP_ONE_STRING:接收单个字符串的系统(Windows)上, 程序名之后的参数按原样连接,供以自身语法读取命令的命令解释器使用;接收参数向量的系统拒绝该标志。 openkal-windows 实现它;openkal-linux 与 openkal-macos 把 SIGHUP 纳入结束请求;openkal-linux 以绝对名 启动需要解释器的程序(#! 脚本的 $0 不再是 /dev/fd/<n>);openkal-macos 把 EBADARCH 与 EBADMACHO 译为 kal_err_not_program。测试成员 openkal 移到这些版本,并观察单字符串标志在 接收向量的系统上被拒绝。GLOBAL 为 GitHub 标签归档,CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal-linux 0.18.2、openkal-musl 0.22.1、openkal-llvm-runtime 0.16.1。 openkal-linux 的结束请求 处理器以私有 futex 唤醒结束字(与 kal_task_wait 的等待一致),等待结束字的执行上下文由此被请求唤醒; 此前共享唤醒到达不了私有等待,以等待结束请求结束的程序在请求后仍不结束。openkal-musl 与 openkal-llvm-runtime 移到 openkal 0.17.1 这一轮:openkal 系列按精确版本固定,一个同时含 mcpplibs.os 0.2.0 与 openkal-musl 0.22.0 的 ok image 图会出现两个 openkal。测试成员 openkal、openkal-musl 随之移动。

  • openkal-windows 0.13.2、openkal-musl 0.22.2、openkal-llvm-runtime 0.16.2。 openkal-windows 的有界等待 按进程字的种类取得句柄:以有界生命期启动的程序由其记录命名,此前对它的每次有界等待都失败, 调用方的时限(mcpp 的 [hooks] timeout_seconds)在 Windows 上不起作用。openkal-musl 与 openkal-llvm-runtime 随之移动;测试成员 openkal、openkal-musl 随之移动。

  • openkal-windows 0.13.3。 环境表在首次查询时于一把锁下填写一次,两个执行上下文同时首次查询时 都读到已填写的表;此前其中一个可能读到空表,把已设置的变量(PATH)报为不存在。管道的有界读以 性能计数器计量时限,此前把每次 1 ms 的睡眠计为 1 ms,而默认计时器下一次睡眠持续约 15.6 ms, 100 ms 的时限约等待 1.5 s。测试成员 openkal 随之移动。

  • openkal-run、openkal-tools、openkal-ld 0.1.1,openkal-musl 0.22.3,openkal-llvm-runtime 0.16.3。 openkal-image 的三个包移到 openkal 0.17.1 这一轮:okrun 把 ok image 导入的名字绑定到 openkal-linux 0.18.2、 openkal-macos 0.15.1 与 openkal-windows 0.13.3,以 KAL_SPAWN_ONE_STRING 启动命令解释器的 image 在 okrun 下得到该标志的语义;三个包仍为同一版本、同一归档。openkal-musl 随 openkal-windows 0.13.3 与 openkal-ld 0.1.1 移动,openkal-llvm-runtime 随 openkal-musl 移动。测试成员 openkal、openkal-musl、openkal-tools 随之移动。

  • openkal-platform 0.17.2。 通用包(universal = true:一个包含两个架构的映像、启动器,自包含时按系统带上运行器); okb 包格式(平台插件经 mcpp.plugins.platform 0.20.0 运行 okld bundle --package);载体作为包的运行器、 并能从内存运行一个映像 zip(单文件);-ffunction-sections -fdata-sections 与 --icf=safe;版本组移到 openkal-image 0.1.3、openkal-musl 0.22.5、openkal-llvm-runtime 0.16.5。GLOBAL 与 CN 的 sha256 一致。

  • mcpp.plugins 0.20.0。 新特性 plugins-platform(模块 mcpp.plugins.platform):平台插件与包格式提供者的 provide_format(声明格式,并在请求该格式的一遍中由暂存包的 mcpp-package.json 生成 artifact action),以及平台的 链接、产物命名、封装与运行主机的带检查的写法(mcpp SPEC-013 协议 17);mcpp::plugins::package 读取暂存包的 mcpp-package.json(SPEC-014 §4.5)。SYCL 构建只有一个 C++ 运行时(libstdc++)。需要 mcpp 2026.10.27.1; latest 仍指向 0.19.1,随 mcpp 2026.10.27.1 发布移动。

  • openkal-platform 0.17.1(新包)。 ok 映像目标 x86_64-openkal、aarch64-openkal 的平台包(mcpp SPEC-013): 工具链 llvm@23.1.3,C 库 openkal-musl 0.22.3,C++ 与编译器运行时 openkal-llvm-runtime 0.16.3,工具 okld、okrun (openkal-tools 0.1.1),编译与链接约定、封装、命名、运行器、载体,宿主组合与 openkal 0.17.1 的版本组。 mcpp 2026.10.27.1 的目标表为这两个目标选用它,工程不再声明运行时与工具。GLOBAL 为 GitHub 标签归档, CN 为 GitCode mcpp-res 镜像,sha256 两处一致。

  • openkal 0.17.2 这一轮:openkal-ld、openkal-run、openkal-tools 0.1.2,新包 openkal-bind 0.1.2, openkal-musl 0.22.4,openkal-llvm-runtime 0.16.4。 openkal-image 0.1.2 定义 okb v1(docs/okb.md): 一个 ZIP 归档,映像以 stored 存放、数据起点按 64 KiB 对齐,okb.json 给出各架构的目录、入口与每个成员的 sha256,okb.sig 对清单签名;okld bundle / okld bundle check 写出并校验它,okrun 运行它;libokrun 增加 okrun_run_okb_bytes、okrun_run_images(从内存运行,不写盘)与 okrun_open_library / okrun_symbol / okrun_close。openkal-bind 是构建插件(模块 mcpp.mcpplibs.openkal_bind, docs/bind.md):以 .okso 加 C 头文件发布的库,在 Linux、macOS、Windows 上经它生成的绑定调用, 边界(long、wchar_t、变参、无原型的回调、未导出的函数)在构建时拒绝。四个包同一标签、同一归档。 openkal-musl 0.22.4 的 renameat2 按标志的含义执行或拒绝(RENAME_NOREPLACE 为 kal_fs_rename_flags,RENAME_EXCHANGE 与其余标志为 EINVAL);此前不读标志,交换会丢失第二个文件。 openkal-llvm-runtime 随 openkal-musl 移动。新增测试成员 openkal-bind(在构建程序中构建一个映像并经 插件绑定,测试经绑定调用映像、映像回调测试程序);openkal、openkal-musl、openkal-tools 随之移动。

  • openkal-ld、openkal-run、openkal-tools、openkal-bind 0.1.3,openkal-musl 0.22.5,openkal-llvm-runtime 0.16.5。 okld bundle <out.okb> --package <树> 由 mcpp 暂存的通用包写出 okb:读取 mcpp-package.json(mcpp SPEC-014 §4.5), 角色为 image 的文件按 lib/<arch>/ 成为成员,各自的架构与 sha256 被核对,入口取 launch.entry;这是 openkal-platform 的 okb 包格式的动作。openkal-musl 随 openkal-ld 0.1.3 移动,openkal-llvm-runtime 随 openkal-musl 移动。测试成员 openkal、openkal-bind、openkal-musl、openkal-tools 随之移动。

  • mcpplibs.os 0.2.0。 mcpp 的操作系统层所承载的内容进入 os:exec(本进程成为另一个程序)、 一个管道按写入顺序承载输出与错误输出、追加写与持久化、卷的容量、place 与 exchange、属主、 处理器数与可用内存、有界读取输入、发往错误流的输出、保留中断的原始模式,以及 Windows 的事实。 基于 openkal 0.17.1(openkal-linux 0.18.2、openkal-macos 0.15.1、openkal-windows 0.13.3);ok image 形态基于 openkal-llvm-runtime 0.16.3 与 openkal-tools 0.1.1。测试成员 os 移到 0.2.0,并观察两个输出 经一个管道按序到达。

Changed

  • CI and compatibility measurements use mcpp 2026.11.3.1. The hosted platform member selects openkal-platform 0.23.3. The index client floor and compatibility runtime baseline are unchanged.

  • compat.miniaudio 0.11.25 以 gnu11 编译(可构建到 wasm32-emscripten)。 Emscripten 上 miniaudio 的 Web Audio 后端经 EM_ASM 内联 JavaScript,Emscripten 在严格的 -std=c* 模式下拒绝 EM_ASM(上游 miniaudio.h §2.6: 不能使用 -std=c*),原来的 c_standard = "c11" 使 mcpp build --target wasm32-emscripten 编译失败;改为 gnu11 后构建并在 node 下运行,启用的后端为 Web Audio 与 Custom(上游在 Emscripten 上不构建需要后台线程的 Null 后端)。 其他平台不受影响(上游 CMake 不设标准,GCC/Clang 默认即 GNU 方言);归档与 sha256 不变,仍为同一版本。

  • 同一归档的包由点名其中一个的成员一并构建。 候选矩阵要求每个新增版本有直接点名它的测试成员; openkal-image 的 openkal-ld、openkal-run 与 openkal-tools 同一标签、同一归档,彼此以 path 依赖到达, 成员 openkal-tools 构建 openkal-tools 时即从同一字节构建另两个。tests/autoupdate/ci.py 的 matrix 对没有直接成员的包,查找本次计划中归档 URL 完全相同且有直接成员的同胞包,由该同胞的任务覆盖; 不同归档的包仍报 no candidate consumer。

  • CI 按包身份选择受影响的成员。 validate.yml 的 select 曾在成员清单中查找描述符短名的 子串:pkgs/o/os.lua 选中 205 个成员中的 113 个(boost-*、macos、cfg(os = ...)、 注释里的 exists),而经 asio、curl 依赖 compat.openssl 的成员一个也未选中。 tests/select_members.py 以 mcpp 的规则读取成员声明的 (namespace, name),沿描述符的 deps 与包归档内清单(按 tag 读 raw.githubusercontent.com;release 资产则读归档本身, 并经 path 依赖到达同一归档的其他清单)陈述的依赖求传递闭包,选出依赖图含被修改身份的成员。 归档以 sha256 固定,已读结果由 actions/cache 保存。读不到的清单记为警告,由每周全量运行覆盖。

  • compat.sycl-runtime 在 Linux 上要求 mcpp:c++-abi=libstdc++。 libsycl.so 在 libstdc++ 上抛出 sycl::exception,而一个进程中的两套 C++ 运行时之间带类型的 catch 不会匹配 (mcpp-community/mcpp#838)。gcc 工具链,或 llvm 加 gcc.libstdcxx,满足该要求;其他构建 在编译前被拒绝。测试成员 sycl-runtime 在 Linux 上陈述 gcc。

  • mpusz.mp-units 要求 mcpp:compiler=llvm(原为 mcpp:c++-abi=libc++):约束来自 GCC 16.1 的模块缺陷,是编译器而不是 C++ 库。compat.glfw 以 requires = { "mcpp:c-abi=glibc" } 取代能力 abi:glibc。

  • openkal-macos 0.14.1、openkal-musl 0.21.1、openkal-llvm-runtime 0.15.6。 macOS 上 经 fork 复制的程序此前不能启动线程(pthread_create 返回 EAGAIN, mcpplibs/openkal-musl#55):kal_space_start 只调用复制原语,而该系统的 fork 在原语前后 由系统库各部分加锁并在副本中更新自身状态。0.14.1 按系统库自身的顺序调用这些导出的部分; 0.21.1 与 0.15.6 移动锁定版本。两个 openkal 测试成员随之移动。GLOBAL/CN 与 sha256 的取法同上。

  • openkal 0.16.0 及随之移动的七个包。 规范新增 kal_task_start_sized(栈大小的下限, 给不出时为 kal_err_no_memory)与 KAL_TERM_PASS_INPUT(环境不改写所输入的字节), 并补述关闭目录即结束其未读完的枚举。openkal-linux 0.17.0、openkal-macos 0.14.0、 openkal-windows 0.12.0、openkal-emscripten 0.5.0 实现三者;openkal-opensbi 0.8.3 只移动规范的锁定版本;openkal-musl 0.21.0 让线程得到所请求的栈并在 raw 模式下区分 回车与 Ctrl+J;openkal-llvm-runtime 0.15.5 移动 C 库的锁定版本。GLOBAL 为上游 tag 归档, CN 为逐字节相同的 gitcode 资源,均按记录的 sha256 核对。 新增两个测试成员:tests/examples/openkal(规范在三平台、各实现在自身平台,以及新声明的 C 层行为)与 tests/examples/openkal-musl(三份报告的原始程序,Linux)。

  • compat.httplib 0.62.0。 在 0.53.1 之外新增版本键(旧键保留)。仍是纯头文件 Form B: 归档根目录仍只有一份 httplib.h(747,115 → 846,648 字节,增量是 SSE 客户端、WebSocket 辅助与加固,全部落在头内,不引入 define、源文件或链接依赖),描述符的内联构建无需改动。 上游 CMake 的 option() 集合与 target_link_libraries 在 0.53.1→0.62.0 之间逐项相同 (两版实测 diff),三平台 ldflags 照旧。0.62.0 上游认识 wolfSSL/MbedTLS 后端,但本索引 没有对应的 compat 包,tls 仍只接 OpenSSL,不新增 feature。实测(Windows / mcpp 2026.10.11.1 / LLVM 23.1.3 + MSVC 14.44):mcpp xpkg parse OK;httplib、httplib-zlib、 httplib-brotli、httplib-no-exceptions 各 1 passed。httplib-tls 与 httplib-zstd 在本机都止步于依赖安装、未编到本包:compat.openssl 3.5.1 的 Windows 安装钩子需要带 Locale::Maketext::Simple 的 Perl,而本机没有 Perl;compat.zstd 1.5.7 的上游 tag 归档含 符号链接 tests/cli-tests/bin/unzstd -> zstd,Windows 上 xlings 无法创建。两项都与本次 改版无关,交 CI 裁决。六个测试成员同步改到 0.62.0。

  • compat.wolfssl 5.9.4。 wolfSSL(TLS/crypto)以 C 源码 compat 形态收录,上游最新稳定 tag 为 v5.9.4-stable。上游的 autotools/CMake 都会在编译前生成 wolfssl/options.h,而内联 描述符无法运行 configure,因此把该步骤的两项输出原样带入:sources 逐条抄自上游 CMake 默认 的 generate_lib_src_list()(5.9.4 的 src/ssl_*.c、src/bio.c、src/x509*.c、 src/pk*.c、src/conf.c 由 src/ssl.c #include,故不单列;wolfcrypt/src/{evp, evp_pk,asn_tsp,asm,ecc_fp}.c 同理);generated_files 写入 mcpp_generated/wolfssl/options.h,即 CMake 默认选项生成的配置头,平台探测改写为 _WIN32/__linux__/__SIZEOF_INT128__/x86_64/aarch64 分支。描述符通过 cflags 与 default-implied feature 同时下发 WOLFSSL_USE_OPTIONS_H,库与消费者编译同一份配置, 结构体布局和功能集不会分叉。默认功能集:TLS 1.3/1.2、AES-GCM、ChaCha20-Poly1305、ECC、 DH、RSA-PSS、SHA-2/3/SHAKE、ML-KEM,并保留 CMake 的加固默认值(NO_OLD_TLS/NO_DES3/ NO_RC4/NO_MD5/NO_MD4/NO_DSA/NO_PSK);Curve25519/Ed25519 与系统 CA 读取在 CMake 默认配置里本就关闭,本包保持一致。CN 镜像尚未发布到 mcpp-res,按先例用纯字符串 url 回退 GLOBAL。实测(Windows / mcpp 2026.10.17.1 / LLVM): mcpp xpkg parse --all-os pkgs/c/compat.wolfssl.lua 三平台 parse OK(38 sources, 2 include dirs,1 generated file);冷 mcpp test -p wolfssl → test result ok. 1 passed; 0 failed(头文件版本串、SHA-256 KAT、AES-256-GCM 往返及 坏 tag 拒绝、RNG、P-256 密钥导出)。新增成员 tests/examples/wolfssl;linux/macOS 两腿交 CI 裁决。

  • compat.soci 4.1.4。 SOCI(C++ 数据库访问层)以 C++ 源码 compat 形态收录:上游 src/core 的 22 个 TU 与 sqlite3 后端的 10 个 TU 编入同一个 lib —— 上游 CMake 把它们拆成 soci_core/soci_sqlite3 两个库,但 mcpp 的 sources 是每包一张表,且没有后端的 core 连 session 都开不了,所以拍平。两处"上游归档里没有、必须补"的东西:3rdparty/sqlite3 是空的 git submodule,由 compat.sqlite3 3.45.3 的依赖边替代(与 compat.sqlitecpp 同构); SOCI 4.1 起 core 与后端共 12 个 TU 无条件 #include <fmt/format.h>,依赖刚落的 compat.fmt 12.2.0 —— 必须是普通形态,且这是实测:先按「取 fmtlib.fmt 的头 + FMT_HEADER_ONLY 编进 自己的 TU」实现过,mcpp test -p soci 一路走到链接期才失败, lld-link: error: duplicate symbol … fmt::v12::detail::dragonbox::cache_accessor<double>::compute_mul (模块对象的 COMDAT 键与 header-only 的不相撞),换成编译库形态后无需任何 define。 三组 CMake PRIVATE 定义分别落地:-DSOCI_SQLITE3_SOURCE=1 进 cxxflags(缺它 soci-sqlite3.h 只给两句前置声明,每个 sqlite3_* 调用都报 "use of undeclared identifier" —— 消费者走的恰是不定义的那条路,所以它必须止步于本包);带引号的 SOCI_LIB_PREFIX/SOCI_LIB_SUFFIX/SOCI_DEBUG_POSTFIX 走 -include shim(引号穿不过 描述符 → mcpp → argv 管道,compat.unixodbc 撞过同一堵墙);SOCI_HAVE_SQLITE3 所在的 soci-config.h 是 CMake file(GENERATE) 产物、不随 tarball 发布,按「只开 sqlite3」 时的输出逐字节复刻进 generated_files。Boost 不做依赖:不加 SOCI_USE_BOOST 时全部源码不碰它。 其余七个后端不做 feature:它们的客户端库要么根本不在索引里(libpq / Oracle / DB2 / Firebird),要么驱动管理器按平台来源天差地别而 feature 的 deps 没有平台门控(odbc 在 linux 靠 compat.unixodbc 源码构建、windows/macOS 靠系统 SDK);以后加后端是一行 sources 加一行 deps,不是重构。实测:mcpp xpkg parse pkgs/c/compat.soci.lua → parse OK; mcpp test -p soci 冷验证 → test result ok. 1 passed; 0 failed(llvm 23.1.3 / MSVC ABI)—— :memory: 建表、绑定参数双向往返、rowset 迭代、indicator 区分 NULL、事务三条路径 (显式 rollback() / 出作用域未 commit 自动回滚 / commit())、后端自带错误码与 constraint_violation 分类、SOCI_VERSION 精确断言。消费侧命令行另有两条旁证:实测无 -DNDEBUG(所以那批断言是活的,不是空测试)、无 -DSOCI_SQLITE3_SOURCE(私有定义 确实没外泄)。⚠️ 后端以 soci::sqlite3 工厂对象取得:session("sqlite3", …) 会走 SOCI 的 动态加载器去 dlopen 一个本包故意不产出的 libsoci_sqlite3.so。⚠️ CN 镜像尚未发布到 mcpp-res,按先例用纯字符串 url 回退 GLOBAL,补传后 sha256 不变。新增成员 tests/examples/soci;linux/macOS 两腿交 CI 裁决。

  • compat.fmt 12.2.0。 {fmt} 的头文件形态(#include <fmt/format.h> + 链接)收录, 即 fmtlib.fmt(模块形态)的非模块兄弟:同一个上游归档、同一个 sha256,身份却分开 —— 想要 #include 写法的工程不必为此背上一个自己从不 import 的模块 BMI。形态是编译库: sources 直接抄上游默认 lib 的两份实现 TU(*/src/format.cc、*/src/os.cc,即 CMake 的 add_library(fmt src/format.cc) 加上 FMT_OS 默认 ON 的 src/os.cc), include_dirs = {"*/include"}(前导 * 吃掉 fmt-12.2.0/ 包装层)。没有 generated_files、没有 anchor,也不需要任何 define:FMT_OS 在 12.2.0 已不被头文件读取, FMT_SHARED/FMT_LIB_EXPORT 是静态链路上不该定义的 DLL 词法,而 src/fmt.cc 是模块 unit, 归 fmtlib.fmt。上游那个独立的 C API 静态库(src/fmt-c.cc + include/fmt/fmt-c.h) 按仓内 sources-only feature 收成 features = { ["c-api"] = … },默认 OFF:只要 C++ 头的 消费者不付这个 TU。门控经负向实测:把 tests/examples/fmt-c 的依赖改回纯版本号,它在 链接期报 lld-link: error: undefined symbol: fmt_vformat 与 fmt_vprint(fmt_arg 的构造在头里是 static inline,未解析符号只可能是 fmt-c.cc 的),带 feature 时包构建报 3 units、不带报 2 units。⚠️ MSVC 的 /utf-8 属消费侧:上游标记它 PUBLIC 的唯一来源是 chrono.h 的 "µs" 字面量,而本包三个 TU 及它们包含的全部头(base.h / format.h / format-inl.h)实测均为纯 ASCII;cxxflags 只作用于本包 TU,替消费侧表达不了,故不声明, 只写进描述符注释。⚠️ CN 镜像尚未发布到 mcpp-res,按 compat.rapidcsv 的先例用纯字符串 url 回退 GLOBAL;补传镜像后改回 { GLOBAL, CN } 即可,sha256 不变。 实测:mcpp xpkg parse pkgs/c/compat.fmt.lua → parse OK;mcpp test -p fmt → test result ok. 2 passed; 0 failed(format.cc 的编译库断言 + os.cc 的 getpagesize/pipe 往返),mcpp test -p fmt-c → 1 passed; 0 failed;.xpkg.lua 快照 里就是本 checkout 这份带 c-api 表的描述符,证明解析没落到远端已发布索引。新增成员 tests/examples/fmt 与 tests/examples/fmt-c;linux/macOS 两腿交 CI 裁决。

  • compat.sdl3 3.4.18。 在 3.4.2 之外新增版本键(旧键保留,与 compat.ftxui 等既有做法一致)。补丁号不等于补丁:这份描述符里真正会失效的东西是源集与两份 签入 config,所以四处都按两个 tarball 实测过,而不是假定 —— src/ 只增 4 个文件 (两个 Vulkan 着色器头落在已整目录 glob 的目录里;另两个是 src/video/wayland/SDL_waylandutil.{c,h},wayland 本就不在任何列表里),签入的 windows/macOS config 与 3.4.2 逐字节相同(两个平台的源集正是从它们反推的, 所以这次抬版本它们照用),linux config 的模板只动三行(删掉的 HAVE__UITOA 本就 未定义,新增的 SDL_EMSCRIPTEN_PERSISTENT_PATH_STRING 只对 emscripten 有意义), 上游 CMakeLists.txt 的源选择未变(唯一的 .c/.m 命中行是缩进)。 ⚠️ 生成的 linux config 不重新生成:它是冻结的 CMake 输出,3.4.18 新增而它不知道 的宏一律读作关闭 —— 与当初裁剪的方向一致,也与「config 只许声明索引真正打了包的 东西」同源。⚠️ CN 镜像 3.4.18 尚未发布到 mcpp-res,按 compat.ftxui 7.0.3 的先例 用纯字符串 url 回退到 GLOBAL(list_cn_urls.lua 明写忽略纯字符串 url,所以 mirror-cn-reachable 对这一条是空集);补传镜像后改回 { GLOBAL, CN } 即可, sha256 不变(镜像按原样重托管 tag 归档)。 实测:windows 本地 mcpp test -p sdl3 编完并跑通 —— 3.4.18 报出 3 个视频驱动, dummy 窗口 320x240、定时器前进,test result ok. 1 passed。linux/macOS 两条腿由 CI 裁决:冻结的 linux config 是这次唯一没有被本地证伪的东西。

  • compat.libserial 1.0.0。 LibSerial 的 SerialPort/SerialStream 以 compat 形态收录:上游 CMake LIBSERIAL_SOURCES 的三个 TU 编成一个 lib,公开头经 include_dirs 暴露。仅声明 linux(公开头以 <termios.h> 开头、实现触及 <linux/serial.h>,消费者用 [target.'cfg(linux)'.dependencies] 门控)。两处上游头 文件缺陷在包内修复:SerialPortConstants.h 用 uint8_t 却未含 <cstdint>,由 generated_files shim 补上;SerialPort.h 的 call_with_retry 用了 C++20 已移除的 std::result_of,libc++ 下整个库编不过,由 install() 改写为等价的 std::invoke_result_t。GLOBAL 为上游 tag,CN 为 mcpp-res/libserial 镜像, sha256 相同。

  • openkal-llvm-runtime 0.15.4。 只移动锁定版本:openkal-musl 0.20.1 携带 openkal-linux 0.16.1(修复线程局部存储镜像的位置)。该包的 examples/cxx 探针 正是发现该缺陷的地方 —— C++ thread_local 对象的 guard 字节落在非零邻居上, 构造函数从未运行;修复后同一探针通过(PR #34)。

  • openkal-linux 0.16.1 与 openkal-musl 0.20.1。 0.16.1 修掉一处潜伏缺陷: 线程局部存储的镜像被放在变量地址之下八字节(段声明 p_align = 8, p_memsz = 56 时,链接器把变量放在 tp - 56,而区域按 16 对齐建成 64 深)。0.16.0 新增的 实现自有 TLS 存储使该缺陷显形:两个带初值的线程局部变量互相读到对方的字节, C++ 的 thread_local 对象的 guard 字节落到非零邻居上而不构造 —— 由 openkal-llvm-runtime 的探针在 runner 上报出。0.20.1 只移动锁定版本。 GLOBAL/CN 与 sha256 的取法与前一行相同。

  • openkal-linux 0.16.0、openkal-macos 0.13.0、openkal-windows 0.11.0、 openkal-emscripten 0.4.0、openkal-opensbi 0.8.2、openkal-musl 0.20.0。 六个同轮仓库的行:GLOBAL 为上游 tag 归档,CN 为字节一致的 gitcode 资源 (sha256 两次取自上游、一次取自 CN,三者相同)。openkal-linux 以 mincore 实测 映射、以 mapping_end - RLIMIT_STACK 与栈下最近映射之上一个 guard gap 的较高者 为下界;openkal-macos 走 _pthread_self 与两个 _np 查询(三个名字补进 port/libSystem.tbd);openkal-windows 走 GetCurrentThreadStackLimits(声明补进 src/win32.h 与 port/kernel32.def);openkal-emscripten 走 emscripten_stack_get_base/_end;openkal-opensbi 只移动锁定版本;openkal-musl 让 pthread_getattr_np 对调用线程给出真实区间、对其它线程一律 ENOSYS。同时修掉 openkal-linux 在 hosted 形态下从未描述自身 TLS 镜像的潜伏缺陷。

  • openkal 0.15.0 与六个同轮仓库。 规范新增 kal_task_stack:一个执行上下文可以 说出自己所在的栈区间(自问自答、不取句柄),用于替换 C 库移植层此前对 pthread_getattr_np 的拒绝。openkal-linux 0.16.0 用 mincore 实测映射并以 mapping_end - RLIMIT_STACK 与栈下最近映射之上一个 guard gap 两者中较高者为下界; openkal-macos 0.13.0 走 _pthread_self 与两个 _np 查询(三个名字同时补进 port/libSystem.tbd);openkal-windows 0.11.0 走 GetCurrentThreadStackLimits (声明补进 src/win32.h 与 port/kernel32.def);openkal-emscripten 0.4.0 走 emscripten_stack_get_base/_end;openkal-opensbi 0.8.2 只移动锁定版本; openkal-musl 0.20.0 让 pthread_getattr_np 对调用线程给出真实区间、对其它线程 一律 ENOSYS,并撤回对应的 [c-abi-absent] 行。同时修掉 openkal-linux 在 hosted 形态下从未描述自身 TLS 镜像的潜伏缺陷(上下文线程指针落在存储区错误一端),新增 tests/conformance_task_tls.cpp 以非零初值观测该镜像。

  • compat.libevent 2.1.13。 Linux、macOS、Windows 分别通过上游 CMake 生成 平台配置头,再由 mcpp 编译 libevent 核心、HTTP/DNS 扩展和对应系统后端; TLS 可选组件未收录。workspace 成员测试事件分派、缓冲区和 HTTP 对象。

  • compat.muduo 2.0.3 与 Boost 头组件。 muduo 仅支持 Linux;内联构建 muduo_base/muduo_net 源码,按上游 2.0.3 的依赖补充 compat.boost-any、 compat.boost-circular-buffer、compat.boost-concept-check 并复用既有 compat.boost-utility。 三个新增 Boost 包各有 workspace 成员;muduo 的成员按 Linux 门控。上游归档使用 GLOBAL 地址, CN 镜像待补。安装钩子仅修补 C++20 移除的 shared_ptr::unique() 与缺失的 <time.h>。

  • compat.yaml-cpp 0.8.0 与 0.9.0。 YAML 1.2 解析与生成,按上游 CMake 目标原样编译 (src/*.cpp + src/contrib/*.cpp),GLOBAL + GitCode CN 镜像字节一致。上游把 YAML_CPP_STATIC_DEFINE 作为静态构建的 PUBLIC 定义;描述符的 defines 到不了消费者, 所以用 yaml-cpp/dll.h 的同名遮蔽头送达,测试在编译期断言它到了(MSVC ABI 上缺它就是 dllimport 链接错误,Linux 上看不出来)。两个版本各有一个测试成员(yaml-cpp、 yaml-cpp-v080),都列入 tests/openkal/members.toml 在 openkal 上测量。

Changed

  • 候选门只在消费者构建候选包的平台上调度它。 tests/autoupdate/ci.py 的 member_platforms 读取消费者清单:无条件依赖在三个平台调度;cfg(os = ...) 或 cfg(windows) 下的依赖只在该平台调度;其余条件(环境、架构)不调度任何宿主作业,由包自身仓库 在目标上测量。mcpp 只锁定宿主解析到的包,向另一平台的 runner 要平台包的锁定证明必然失败; test_ci.py 覆盖了这条规则。

  • 站点的 openkal 分面改为两个取值:openkal-ecosystem 与 openkal-compat。 原先的 「openkal itself / runs on openkal / fails on openkal」是句子而不是名字。构成 openkal 的 包归入 openkal-ecosystem;测试项目在 openkal 依赖图中测得 runs 的包归入 openkal-compat。只测得 builds 或 fails 的包不再归入分面,其页面仍按目标列出测量结果 与第一条诊断。

  • openkal 测量按改动选成员,不再每次全量。 compat.py select --base <merge-base>: 改动 openkal 家族描述符、pins.toml、compat.py 才测全部成员;改 members.toml 只测 新增或改动的条目([not-portable] 计入所指成员,[excluded] 不选);改 tests/examples/<成员>/ 测该成员;改描述符测依赖它的成员。selftest 为每条规则各加一例。

  • openkal 的 Windows 目标改名为 x86_64-windows-musl。 依赖图在 Windows 上呈现的是 musl 的 C 环境,不是 MinGW;x86_64-windows-gnu 会被读成 mingw-w64 构建。实测同一依赖图: cli11、zlib、cmp-module 仍 runs,curl 仍停在同一条 curl_setup.h:591。2026-09-23 之前的 结果仍记在旧名下。

  • CN 镜像可以由库的维护者自己托管。 check_mirror_urls.lua 要求 CN 是 gitcode 的 release 资产(https://gitcode.com/<owner>/<repo>/releases/download/…),不再限定 mcpp-res 组织;mcpp-res 仍是默认。#463 起 main 上的 lint 因 ZheFeng7110.boost 的维护者镜像而失败,现在通过。

Fixed

  • 索引制品按提交只定一次字节,两个托管端提供同一份。 同一提交重跑发布(夜间 cron) 会重新打包:条目时间取自检出,于是字节不同;GitHub 以 --clobber 替换了资产,GitCode 不能替换而保留第一份,两端指针却都改成第二份的摘要。2026-09-16 实测 v7649883: GitHub 78535f36…(553573 字节)、GitCode d89135a3…(553557 字节),树相同。CN 客户端 因此拒收 GitCode 的字节并回落到 GitHub(mcpp-community/mcpp#648)。现在 tools/publish_mcpp_index.sh 先复用已发布的同版本字节(先问不可替换的 GitCode), 新打包则可复现(排序、固定属主/权限/条目时间、gzip -n),发布末尾逐端取回比对摘要, 不一致即失败。xim-pkgindex 在 2026-09-05 以同样方式修过同一缺陷。

Changed

  • farm 只携带这个 runtime 够得到的东西,并且把「一个钉挪动」这件事在整条链上补齐。 三个 farm(compat.glx-runtime / compat.opencl-runtime / compat.vulkan-runtime) 一起到 2026.09.11,消费者链 compat.glfw 3.4.0.1、compat.opencl 2026.09.11、 compat.vulkan 1.4.357.2、compat.sycl-runtime 2026.09.11 同步。

    ⭐ 剔掉 libnvidia-pkcs11*,并撤回它带来的 OpenSSL 依赖。 它是加密令牌模块, 由应用自己的 PKCS#11 配置加载,不由任何 GPU 驱动派发;进 farm 只因为名字匹配 libnvidia*.so.*。判据是 LD_DEBUG=libs(带对照):两条链上 pkcs11 出现 0 次,而驱动确实够得到的 libnvidia-glvkspirv 出现 6 次、OpenCL adapter 出现 23 次 —— 对照证明这个仪器分得开,所以 0 是读数不是沉默。它们也是 farm 里唯一需要 libcrypto 的成员,随之消失的还有那条无解的 libcrypto.so.1.1(OpenSSL 1.1 上游 已 EOL)。

    ⚠️⚠️ 一个更早的判据什么都没测到:把成员删掉看示例还跑不跑 —— 删掉 libnvidia-glvkspirv 示例照样跑。原因是被测二进制和被改的 farm 不是同一个 (产物目录有两个,钉着不同版本)。判据又一次指错了对象。

Fixed

  • 三处只有真跑一遍才会现形的缺陷。

    ⚠️⚠️ 排除循环遍历了模式表却把模式写死。 compat.vulkan-runtime 的 never_farm_patterns 绑定了 pat 然后传了字面量 libnvidia-gtk*,于是这张表 看起来是列表、行为上只有一条。往里加 libnvidia-pkcs11 毫无效果 —— farm 依旧 81 个成员、两个 PKCS#11 都在,这是「排除」写完之后才发现的。

    ⚠️⚠️ readelf -d 不是传递的,一趟补不完。 上一版用 ldd(答案是整个传递闭包) 所以一趟够;换成 readelf 是对的(它答文件说什么,而不是这台机器能不能解析), 但这一轮补进来的库会带来自己的依赖。实测:compat.glx-runtime 第一次真安装, farm 从 52 涨到 77 仍缺 9 条,包括 libLLVM.so.20.1 和 libstdc++.so.6。 现在迭代到不动点(带上界防环),再测 86 个成员、0 缺口、0 封条。

    ⚠️ 找不到 readelf 时那一趟静默返回空,读数与「已完全闭合」相同;现在明确告警, 且 compat.glx-runtime 的工具查找也先查 store 再查 PATH。

    实测(本机,真驱动):compat.glx-runtime 86 成员 / 0 缺口,零直接宿主触达 —— 4 条走 xim:nvidia-gl-host-link、24 条走其它 xim 载荷、其余走 subos 库视图。 SYCL 示例 members 49 / walked 49 / findings 无,Vulkan 示例 members 56 / walked 56 / findings 无,两者都在 RTX 4080 上跑出正确结果。

Fixed

  • 两处只有把 glx 那一版真正跑一遍才会现形的缺陷。 上一轮我量了 opencl 和 vulkan,compat.glx-runtime 的新逻辑从头到尾没有被执行过。

    ⚠️⚠️ DT_NEEDED 里可以是绝对路径。 这个 farm 的四个 glvnd 厂商入口 (libEGL_nvidia、libGLESv1_CM_nvidia、libGLESv2_nvidia、libGLX_nvidia) 直接写着 /lib/x86_64-linux-gnu/...。loader 对这类条目直接打开、完全不走 搜索路径,所以 farm 既服务不了它也不该为它封 unserved —— 而把它当 soname 会 去查一个带斜杠的名字,并且造出一个名字是路径的 unserved 链接。三个包一并 跳过这类条目。

    ⚠️ 找不到 readelf 时那一趟静默返回空,读数与「farm 已完全闭合」一模一样。 这正是这批改动要消灭的那种混淆,只是掉到了工具查找这一层。现在会明确告警, 并且 compat.glx-runtime 的工具查找也和另外两个一样先查 store 再查 PATH —— 这个包跑在从未被要求装工具链的机器上。

    实测(本机,对着已装的 glx farm 走同一套逻辑):52 个成员、跳过 4 条绝对路径、 19 条需补,19 条全部来自生态载荷,0 条 unserved,没有路径形状的条目。

Changed

  • compat.vulkan 1.4.357.1 —— 移动一个钉,需要一个新版本。 上一条把 compat.vulkan 对 compat.vulkan-runtime 的钉从 2026.09.07 挪到 2026.09.10,没有抬 compat.vulkan 自己的版本。对一台已经装着 compat.vulkan@1.4.357.0 的机器,那份已安装副本里记着的仍是 2026.09.07; 而同时自己也直接声明 compat.vulkan-runtime 的消费者(mcpp 的图形示例在 cfg(linux) 下就是这么写的)拿自己的钉去比,于是构建停在 irreconcilable versions。

    ⚠️⚠️ 本地测不出来:重新解析过索引的机器两边都读到 2026.09.10,毫无冲突。 它是在 CI 上、一个 ~/.mcpp 是热的 runner 上现形的。「本机绿」在这一类升级 问题上等于零信息量。

    ⭐ 规则:一个包如果钉着另一个包的版本,那个钉挪动时它自己必须换版本 —— 换版本买到的是一次重装,重装才会按当前索引重新记录。1.4.357.0 保持原样, 已经持有它的机器照原样解析。

Changed

  • 三个 host farm 改为对自己的成员负责,并且对宿主只保留一条具名的触达 (compat.glx-runtime 2026.09.10、compat.opencl-runtime 2026.09.10、 compat.vulkan-runtime 2026.09.10)。

    这三个包的成员由文件名模式决定,而完整性(如果检查的话)对着的是另一个 集合 —— ICD 清单里的库。模式存在的理由恰恰是「专有驱动会按名字 dlopen 自己 家族的成员,没有任何 DT_NEEDED 遍历看得见」;既然这么说了,那些成员在别处也 得当作可达的 —— 而它们不是。从来没被验证的,正是模式为之存在的那一半。

    实测(装了 NVIDIA 驱动的宿主,用 mcpp 自己的 dlopen 面检查): compat.glx-runtime 52 个成员缺 30 条闭包边(它根本没有闭包遍历)、 compat.vulkan-runtime 76 个缺 5 条、compat.opencl-runtime 缺 4 条 —— 最后这 4 条就是 mcpp-index#376 报的那几条(该 issue 标题写的是 vulkan, 实际观测到的来自 opencl)。

    ⚠️ 配方里「种子不能取整个 farm」的理由测的是排除之前的集合。 它写着闭包会 拉进 64 个库、GTK 在其中 —— 那是对「模式匹配到的每个文件」成立,因为 libnvidia*.so.* 也匹配驱动的设置界面。farm 是模式匹配减去 never_farm_patterns,对那个求闭包在本机只新增 5 个,GTK/GLib/Pango/Cairo 一个都没有。结论会被复查,理由不会。

    ⭐ 新规则:一个成员需要的每条 soname 都有明写的答案,没有静默分支。

    1. 生态发布了它 —— 在 xpm.linux.deps 里声明,从已装载荷取 (新增 xim:openssl、xim:mesa);
    2. 不可再分发的专有驱动用户态 —— 也走包:新增 xim:nvidia-video-host-link 拥有「宿主的 libnvcuvid.so.1 在哪」这一个 问题,和 libcuda-host-link/nvidia-gl-host-link 同形;
    3. 两者都不是、也不可能成为 —— 写进配方的 UNSERVED 表并附理由 (今天只有 libcrypto.so.1.1:OpenSSL 1.1 上游已 EOL,而只有 NVIDIA 的 PKCS#11 提供者要它,没有任何 OpenCL/Vulkan 入口够得到);
    4. 以上都不是 —— 安装时打警告点名。这一条是关键:farm 从生态之外拿了什么, 必须是有人写下来的清单,而不是残留物。

    没有任何一条分支会为成员去 /usr/lib 收一个新文件。 compat.glx-runtime 一条都不收:那 30 条全部来自已装载荷(4 条 libnvidia-* 来自 xim:nvidia-gl-host-link,其余 26 条来自 xim:graphics 拉起来的栈)。

    ⭐ 判据落在 mcpp 会问的那个问题上:成员的 DT_NEEDED 用 readelf -d 读, 归属只对着 farm 这一个目录判。先前用 ldd 是错的 —— 它答的是「在这台机器 上能不能解析」,而这台机器包含宿主默认目录,于是宿主碰巧有的 soname 读成已解析、 从不被记录,而消费者的搜索路径里没有宿主。实测:libcrypto 那两条对这一趟不可见, 却被 mcpp 在上一层从同一个目录报了出来。

    实测结果(本机,opencl farm):members 48 / walked 47 / missing 0, 只剩 libcrypto.so.1.1 一条 dangling —— 正是明写为 unserved 的那条。 改动前是 4 条 missing。

    ⚠️ 抬版本键是必须的:install() 的产物烤进已安装载荷,不换键的机器会一直留着 未闭合的 farm。消费者 compat.glfw / compat.opencl / compat.vulkan 同步重钉。

Added

  • 收录 compat.sdl3 3.4.2 —— SDL3 窗口/输入/音频层,从源码构建(形态 E)。 它是 compat.sdl2 的兄弟而非替代:两者是不同 API、不同 soname。 比 SDL2 好办的两点都是实测:tarball 没有符号链接 (tar tvzf|grep -c '^l' → 0),所以不需要 SDL2 那种 -nosymlinks 重打包托管; 以及配置分发器是上游自带的 —— windows/macOS 的 config 都是签入的, 只有 linux 会掉进 SDL_build_config_minimal.h(那份根本没有视频驱动)。 所以只生成一份 config,而且只有 linux 用它。 ⚠️ 生成它必须用索引自己的工具链 + 索引自己的 X11 头 —— mcpp 的 gcc 自带 sysroot,看不见 /usr/include,不喂索引的头 SDL 的检测会直接失败退出。 ⚠️⚠️ config 只许声明索引真正打了包的东西,这是规则不是偏好:CMake 探的是 它运行的那台机器,宿主有什么就开什么,然后在这里编不过。三个是靠失败的构建 一个个抓出来的 —— XSCRNSAVER(X11/extensions/scrnsaver.h 找不到)、LIBTHAI、 HIDAPI_LIBUSB;XTEST/XSYNC 一并预防性关掉。剩下的是可核对的:配置里所有 会被 dlopen 的库共 7 个,每一个都有对应的包(fribidi + X11 六件套), 与 linux.deps 一一对应。 源集不是"读 CMakeLists 猜的":configure 之后从 CMakeFiles/SDL3-static.dir/build.make 把 CMake 真正选中的 266 个源读回来, 归并成 73 个整目录 + 1 个部分目录(src/core/linux,跳过 dbus/IME 那 6 个 文件 —— 与 compat.sdl2 跳过的是同一批,它们不自 guard)。 macOS/Windows 不用生成的 config,所以它们的源集是从签入 config 里开了哪些 driver 反推的;windows 有一处不显然:SDL_THREAD_GENERIC_COND_SUFFIX / _RWLOCK_SUFFIX 意味着条件变量和读写锁回退到 generic 实现,所以要单独带上 thread/generic/SDL_syscond.c 与 SDL_sysrwlock.c —— 只这两个,其余四个 与 windows 版同名。 测试用 SDL 的 dummy 视频驱动,三个平台上无显示器都能跑:断言头与运行时 版本一致、编译进来的驱动表里有 dummy 与 offscreen(掉进 minimal config 就一个 都没有)、dummy 驱动真能初始化并建出 320x240 的窗口和同尺寸 surface、 以及计时器会前进。 实测:linux · gcc 16.1.0 与 linux · llvm 22.1.8 两条腿都编过(267 个 TU)并跑通; macOS/Windows 由 CI 裁决。CN 镜像 gitcode.com/mcpp-res/sdl3 已建并验过逐字节相同。

  • 收录 vulkan-rt 依赖的八个通用库,一次补齐:compat.glm 1.0.2、 compat.doctest 2.4.12、compat.argparse 3.2、compat.mio 2023.3.3、 compat.gzip-hpp 0.1.0、compat.cpptrace 1.0.4、compat.libassert 2.2.1、 compat.libcoro 0.16.0。八个都带已验证的 CN 镜像 (gitcode.com/mcpp-res/<slug>,逐个比对 sha256 与 GLOBAL 逐字节相同, 8/8),八个都带 workspace 成员做行为断言。 四个不是「拉个头文件就完事」,记在配方里: ⚠️ compat.gzip-hpp 冻结在一个已经编不过的点上:utils.hpp 六处、 decompress.hpp 一处用 uint8_t 却不 include <cstdint>(实测 gcc 16.1.0)。 而且它是消费者侧失败 —— 本包一个 C++ TU 都没有,cxxflags = {"-include", "cstdint"}(compat.redis-plus-plus 的修法)到不了出错的 TU。唯一可用的杠杆是 同名遮蔽头 + #include_next,与 compat.catch2 修 <new> 是同一招; include_dirs 因此必须 mcpp_generated 在前,调换两行会静默失效。 ⭐ compat.cpptrace 是形态 E 去掉 config 头:六个符号后端、六个 unwinder、 三个 demangler 每个文件自己 #ifdef,所以源列表是一条 glob,配置全在 defines。 选的后端一律零外部依赖:unix 走 libgcc 的 _Unwind_Backtrace + dladdr + __cxa_demangle,windows 走 DbgHelp。⚠️ 代价写在配方里:dladdr 不读 DWARF, 所以栈帧有函数名、没有 file:line;要行号得再加一个 libdwarf 包,留作 feature。 compat.libassert 依赖上面那个(上游是 FetchContent 一份进自己的树,这里是 正经依赖,消费者链两次也只有一份 cpptrace);magic_enum 不需要 —— 读 CMakeLists 会发现它只在 LIBASSERT_BUILD_TESTING 下打开,库源码一次都没提过它。 ⚠️ compat.libcoro 只出核心:上游 networking 默认开,但它的 c-ares 在 vendor/c-ares 这个 git submodule 里,而 GitHub 归档从不含 submodule (实测 find vendor -type f → 0 个文件)—— 这个产物根本编不出网络那半。所以源列表 是上游 LIBCORO_SOURCE_FILES 在 if(LIBCORO_FEATURE_NETWORKING) 之前的部分, 逐条转录而非 glob(scheduler.cpp/poll.cpp/epoll/kqueue/net/ 全都不自 guard)。 另外 coro/export.hpp 是 generate_export_header 生成的,tarball 里没有, 缺了它第一个 TU 就 fatal error;快照进 generated_files,CORO_STATIC_DEFINE 走 defines(要到消费者)而非 cxxflags。 测试都断言真行为而非「能编译」:glm 断言叉积/列主序/GLM_FORCE_DEPTH_ZERO_TO_ONE 下近平面映射到 0;gzip 断言 gzip magic + 真的变小 + 往返;cpptrace 断言四层调用链 的帧数与互不相同的返回地址;libassert 走失败路径,断言报告里有表达式原文、 消息和两个操作数的值,并且拿到了非空 stacktrace(这条同时证明 cpptrace 是传递到达的); libcoro 用 200 个协程在 coro::mutex 下累加。

  • 收录 khronos.vulkan-hpp 1.4.357.0 —— Vulkan 的 C++ 绑定,按 Khronos 现在自己 发布的形态消费:import vulkan; / import vulkan_video;。⭐ 这是本索引第一个走 形态 C 第一条分支的包(上游自带 .cppm,直接点名),此前所有模块包都是合成 包装体。描述符里没有一行包装代码:导出面是 Khronos 从 XML registry 生成的。 载荷取 Vulkan-Headers 的 tarball,与 compat.vulkan-headers 同一个 URL、 同一个 sha256 —— Khronos 把生成好的 vulkan.cppm / vulkan_video.cppm 随每个 Vulkan-Headers tag 一起发。指向 Vulkan-Hpp 仓反而更差,三条都实测过:该仓没有 vulkan-sdk-* tag(404),Vulkan-Headers 在那里是 git submodule 而 GitHub 归档 永远不含 submodule,以及由此产生的第二份 vulkan/ include 根会让 vulkan.hpp 由 -I 顺序决定。同一份 tarball 则让两个包不可能错配 —— 模块单元开头就是 VULKAN_HPP_STATIC_ASSERT( VK_HEADER_VERSION == 357 )。 命名空间取 khronos 而非 compat(本索引里 namespace 是消费形态的契约: compat.* 按头文件消费,归属 namespace 承诺 import);模块名保持上游的 vulkan / vulkan_video,不加索引前缀,否则所有 Vulkan-Hpp 文档对 mcpp 用户 都是错的。import_std = true 不是偏好:单元第 27 行是无条件的 export import std;,上游 CMake 也正因此把模块目标 gate 在 23 IN_LIST CMAKE_CXX_COMPILER_IMPORT_STD 上。依赖取 loader (compat.vulkan)而不只是头:Vulkan-Hpp 默认 静态 dispatcher (VULKAN_HPP_DISPATCH_LOADER_DYNAMIC 在没有 VK_NO_PROTOTYPES 时为 0), vk::enumerateInstanceVersion() 会编成对 vkEnumerateInstanceVersion 的直接 调用,只依赖头会得到一个"能编译、每个消费者都链接失败"的包。 与上游 Vulkan::HppModule 一致地不定义任何 VK_USE_PLATFORM_*:那些宏按 平台互斥、无法做成可移植的 feature,而可移植路线也不需要它们 —— GLFW/SDL2 交回 的 VkSurfaceKHR 包成 vk::SurfaceKHR{ raw } 即可,surface/swapchain 本身在 模块里是无条件存在的。 新增 workspace 成员 tests/examples/vulkan-hpp-module(两个测试:module.cpp 全文无 #include,断言枚举量取值、sType 默认、format_traits 的 constexpr 结果、raii 层的编译期成员,以及经静态 dispatcher 打到 loader 的两次真实调用; video.cpp 单独证明第二个模块单元被编译 —— 它 import vulkan;,只能排在第一个 之后,而 sources 只是一张无序的表)。 实测:linux · gcc 16.1.0 与 linux · llvm 22.1.8 两条腿都产出两个 BMI/PCM 并跑通; macOS 与 Windows 走的是与 llvm 腿相同的 clang 路径,其运行期一半早已由 tests/examples/vulkan 在三条腿上证明(调用的是同一批 loader 入口)。 ⚠️ x86_64-windows-gnu(mingw)不可用,也不是 CI 腿(索引的 windows 工具链是 llvm/MSVC ABI):GCC-on-PE 把模块归属的函数内静态量 vk::errorCategory@vulkan()::instance 放进消费者对象的普通 .bss,与模块对象里 的 COMDAT 副本撞成 multiple definition;且 compat.vulkan 的 windows 入口是 MSVC 形态的 vulkan-1.lib,mingw 的 ld 找不到。两条都不是描述符能修的。

  • 收录 mcpplibs.rules-cuda 0.1.0 —— 把「怎么编一个 CUDA 设备翻译单元」收成一条 可 import 的构建规则(host-module = true)。⭐ 一个仓库都不用新建,与 grpcgen 同形:描述符指向 mcpp 自己源码 tarball 的一个子路径 (*/examples/09-cuda-kernel/rules-cuda/mcpp.toml)。规则与它所讲的协议 (构建程序协议 v7)由同一次发布产出,指向同一份 tarball 因而不是权宜之计, 而是让两者不可能错配。需要 mcpp >= 2026.9.5.2。 实测:示例工程去掉 path 依赖、改写一行 [dependencies.mcpplibs] 后, 在 RTX 4080 上构建并跑出 12 24 36 48。

  • 收录 CUDA 设备侧的六个适配包:compat.cudart(CUDA Runtime)与 compat.cublas / cufft / curand / cusolver / cusparse(五个算子库)。 载荷一律来自 xim(xpm.linux.deps 接线),本仓库只回答「怎么对它构建」: install() 把载荷的 include/ 与 lib/*.so* 链进包自己的目录, include_dirs / -L / runtime.library_dirs 因而全部落在包内。 一律走 12.x 线 —— 设备运行时不得新于它将遇到的驱动,而 xpm.<platform>.deps 按 OS 读取而非按版本,所以一份描述符只指一条线。 ⚠️ 两处上游造成的耦合写在配方里:compat.cudart 额外依赖 xim:cuda-nvcc, 因为 12.x 线的 crt/host_config.h 在编译器组件里而 cuda_runtime.h 无条件 include 它;以及 NVIDIA 的 .so 带 RUNPATH = $ORIGIN,它会关掉可执行 文件继承来的 DT_RPATH,所以 glibc 2.34 合并进 libc 的三个存根 (librt.so.1 / libpthread.so.0 / libdl.so.2)必须一并链进同一个目录 —— 否则程序在 main 之前就以 librt.so.1: cannot open shared object file 退出。

  • 新增工作区成员 tests/examples/cuda-curand:无设备的机器上断言库能加载并 应答(即上面那条 $ORIGIN 缺陷的判据),有设备时再断言生成值落在 [0,1] 且均值接近 0.5。五个算子库包由同一模板生成,-l 名逐个读自上游归档; cuRAND 载荷最小(85 MB,对比 cuBLAS 的 933 MB),因此它是每个 PR 都跑的那个。

Changed

  • compat.sycl-runtime 2026.09.10 与 compat.cuda-driver 2026.09.10:驱动一侧 的 farm 由枚举哨兵目录得到,不再手写 libcuda.so.1 一个名字,并把哨兵 依赖钉到 xim:libcuda-host-link@0.0.2。手写的那一半正是错的那一半: libur_adapter_cuda.so.0 的 DT_NEEDED 里除 libcuda.so.1 之外还有 libnvidia-ml.so.1,farm 没有携带,适配器加载失败,CUDA 后端整个消失, 程序以退出码 134 终止且不打印任何异常文本(mcpp#596)。哪些驱动库存在是 哨兵包的问题;读它的目录得到的 farm 无法与它不一致,而写死文件名的 farm 已经 不一致了。旧版本键保留:本文件只有一个 install() 且不读 pkginfo.version(), 所以旧钉今天安装得到的仍是当前 farm,新版本键的作用是让已经装过该目录的机器 重新安装。

  • compat.sycl-runtime 明确声明不服务 libOpenCL.so.1。载荷自带 OpenCL 适配器,而 compat:opencl 会连带引入宿主专有 OpenCL 驱动的 farm,把一份 随机器而变的厂商面塞进每一个 SYCL 工程;实测中它还提供了 libnvidia-ml.so.1, 从而遮住上一条正在修的缺口。需要该后端的工程在自己的 manifest 里声明 compat:opencl。

  • compat.cuda-runtime 改名为 compat.cuda-driver,并改正 repo 字段。 NVIDIA 词汇里 "CUDA Runtime" 专指 libcudart,而本包 farm 的是驱动的 libcuda.so.1;它的 capabilities / provides 从第一版起就写作 cuda.driver, 只有包名不一致。旧条目冻结保留,compat.cuda-runtime@2026.09.05 继续解析到 同一份实现;工作区成员 tests/examples/cuda-driver(原 cuda-runtime)同时 依赖新旧两个名字,让这条过渡承诺有判据。

  • 收录 compat.boost-beast 1.92.0（Boost.Beast，HTTP/WebSocket），沿 modular-boost 拆包路线一次性补齐其 24 个传递依赖：boost-asio、boost-align、boost-bind、 boost-compat、boost-container、boost-container-hash、boost-core、 boost-describe、boost-endian、boost-intrusive、boost-io、boost-logic、 boost-move、boost-mp11、boost-optional、boost-predef、 boost-preprocessor、boost-smart-ptr、boost-static-string、boost-system、 boost-type-index、boost-utility、boost-variant2、boost-winapi。 29 包 include 树两两不相交、闭包逐 include 核实；boost-asio 经 default feature 携带 BOOST_ASIO_DISABLE_BOOST_CONTEXT_FIBER / ..._DATE_TIME 与 BOOST_ASIO_HAS_THREADS（llvm-on-Windows 无 _MT/BOOST_HAS_THREADS， 不钉定会静默退化为 null_thread 且 VERSION_TAG 跨 TU 漂移），保持家族 header-only。新增 boost-beast、boost-asio、boost-family 三个工作区 成员；其中 boost-family 为大测试成员，一个工程 6 个测试文件覆盖全部 23 个没有专属成员的小依赖包（core/smart-ptr、container/intrusive/ optional/static-string、mp11/describe/preprocessor/type-index/predef、 system/compat/bind、endian/container-hash/logic/align、io/utility/ winapi）。

  • 收录 gzj-creator.galay 5.0.2 原生 Form-A 模块包，覆盖 galay.utils 与 galay.kernel 默认模块，并加入 Unix 示例工程和索引文档。

Fixed

  • tests/examples/sycl-runtime 的判据由三个手写 soname 的 dlopen改为 对 farm 全体成员做 DT_NEEDED 闭包走查。farm 有 26 个成员而断言只有三个 名字,坏掉的两个不在其中,所以这条判据在缺陷存在期间一直是绿的。改用 dlopen 全体成员仍然不够:dlopen 量的是进程,而进程的搜索路径上不止本包放的东西 —— 实测中另一个 farm 提供了 libnvidia-ml.so.1,把本包的缺口遮成通过。 现在的走查只看 farm 自己,并区分三种读数:解析到、farm 里存在但悬空(无驱动的 机器,记 note)、farm 根本没有(打包缺口,失败)。三条腿都实测过:补全后 26/26 通过;拿掉 NVML 后点名成员与 soname 失败;把驱动链改为悬空后 24/26 通过。

  • 跟进 Galay 5.0.1 对 C++23 module prelude 的跨平台 intrinsic 头文件守卫修复， 避免 Clang 在 Linux/macOS 上错误转发 intrin.h。

  • 跟进 Galay 5.0.2 将 AioCommitAwaitable::await_suspend 的类外模板定义放回 galay::async 命名空间，修复 Clang 22 导出 galay.kernel 时的模块语义错误， 同时保留 Linux USE_EPOLL AIO 后端行为。

Docs

  • 记录 Galay 5.0.2 归档的双下载 SHA256 校验，以及 PR #285 的全平台 CI 验证结果。