openkal-opensbi 0.1.3 - #249
Merged
Merged
Conversation
…ll link
0.1.2 定义了它拥有的能力字,没定义它不拥有的那些。规范里的查询是
property 对象上的内联函数,因此**只要程序问一句「有没有文件系统」,
就取了 `kal_fs_props` 的地址** —— 这个引用来自提问本身,不来自任何
文件系统调用:
ld.lld: error: undefined symbol: kal_fs_props
>>> referenced by fs.cppm:136
>>> obj/main.o:(kal::fs::properties@openkal.fs())
⭐ 于是一个后端在**恰好是这个问题存在意义所在的那类机器上**,
让这个问题编不过去。0.1.3 把读零的字也定义出来。
镜像两侧字节一致(27099 bytes,sha256 8da3f381…),CN 对象已 curl 回来
解包核验过 —— gtc 报 uploaded 而对象 404 出现过,报告不算数。
ZheFeng7110
pushed a commit
to ZheFeng7110/mcpp-index
that referenced
this pull request
Sep 10, 2026
) 两个包在装了同名系统开发包的机器上会拿错头,而 CI 和本地一直看不见:默认 工具链 gcc 是通过 --sysroot 进 xlings subos 编译的,那里 /usr/include 干干 净净。换到 llvm(无 sysroot)宿主机的头就进了默认搜索路径,两个都当场炸。 ## compat.ffmpeg:-idirafter 排在系统目录之后 源码根走 include_dirs_after 是 mcpplibs#249 为 macOS 修的 —— 大小写不敏感的文件系统 上 ffmpeg 的 VERSION 会遮蔽 libc++ 的 <version>。但 -idirafter 的语义是排在 **系统目录之后**,于是在装了 libavutil-dev 的 Debian/Ubuntu 上 (/usr/include/x86_64-linux-gnu 是默认搜索目录),vendored 8.1.2 的每一个 `#include "libavutil/..."` 都输给宿主机的 6.1.1。 不是优雅降级:全局 -DHAVE_AV_CONFIG_H 让宿主机的**公开**头去 include dev 包 根本不装的私有头('x86/bswap.h'、libavutil/internal.h),再叠加 6.x/8.x 的 类型错配(enum AVAlphaMode 不完整、SwsContext 少 typedef)。 改成按 OS 放置,且**只能二选一**:同一个目录同时出现在 -I 和 -idirafter 会 被编译器去重到最后那个位置,保留一份冗余的 -idirafter 就会静默抵消 -I。 clang 22.1.8 上实测过:同一条命令行,只删掉重复的 -idirafter 就编过。 linux → include_dirs。文件系统大小写敏感,VERSION 遮蔽不了 <version>; 而它是唯一有系统 ffmpeg 可输的平台。 macosx → include_dirs_after,mcpplibs#249 原样。 windows → include_dirs_after。NTFS 同样大小写不敏感,换 -I 会把 mcpplibs#249 带 回来,而那边的系统目录里没有 libav*。 生成器 tools/compat-ffmpeg/gen_multiplatform.py 同步改。per-OS 快照已不在, 描述符是手改的,两边保持一致。 ## compat.catch2:上游 2.13.10 漏 #include <new> 单头调了两次 new(std::nothrow)(catch.hpp:977 / :14594)却从不包含 <new>。 libstdc++ 会从别的头把它带进来,libc++ 不会,于是每个 clang 消费者都挂在 "no member named 'nothrow' in namespace 'std'"。Catch2 v2 上游已 EOL。 修法是在 mcpp_generated 里放 shim:#include <new> 后 #include_next 到上游那 份,而不是 patch 一份 17k 行的头 —— sha256 钉住的 tarball 仍是唯一事实来源。 这要求 mcpp_generated 排到 include_dirs 最前,因为 #include_next 从本文件所在 目录之后继续搜。 不能用 cflags 解:描述符的 cflags 到不了消费者的 TU(实测消费端只拿到 include_dirs 和 -std),而 catch.hpp 恰恰是消费者包含的。 ## 删除冻结的 mcpplibs:opencv@0.0.10 mcpplibs#165 已把它迁到 opencv:opencv@5.0.0 并冻结保留。索引内三个消费成员早就写成 限定形式,删除零 fallout;顺带修掉三处说自己在消费裸名的过时注释。 注意 `mcpp new -t opencv:imgproc` 会随之失效 —— `-t` 的 spec 语法里冒号是 模板分隔符,表达不出 ns:name,所以在 mcpp 给限定名留出位置之前,模板路径 拿不到 opencv。 ## 验证 在一台装了 ffmpeg 6.1.1 dev 头和 Catch2 v3 的机器上,llvm@22.1.8 与 gcc@16.1.0 双工具链: ffmpeg 消费者 llvm 2311 个 .o(libswscale 71,原先整批全灭);二进制断言 avutil_version()>>16 == 60 通过 —— 用的确是 vendored 8.1.2 gcc 回归 2281 个 .o,同样通过,走新的 -I<root> + sysroot opencv 端到端 import opencv.cv; + cvtColor/GaussianBlur,llvm 下通过 catch2 catch2 / catch2-main / catch2-v2 三成员双工具链通过 已知未修:catch2-v2-main 在 llvm 下仍失败。catch2_main.cpp 用 __has_include(<catch2/catch_all.hpp>) 判 v2/v3,该探测同样会落到系统目录, 在装了系统 Catch2 v3 的机器上把 v2 判成 v3,链接报 undefined Catch::Session。 同一类问题,但要不问文件系统就知道版本,得等 per-version build blocks (mcpp#290)。回退本提交后同样失败,是既有问题而非本次引入。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
0.1.2 只定义了它拥有的能力字。规范的查询是 property 对象上的内联函数,因此
kal::fs::has(...)这类提问本身就取了kal_fs_props的地址,而后端把读零的字省了:结果是一个后端在恰好是这个问题存在意义所在的那类机器上,让这个问题编不过去。上游 mcpplibs/openkal-opensbi#3 已合入并打了 0.1.3。
镜像已核验:GLOBAL 与 CN 两侧 27099 bytes、sha256
8da3f381…一致,CN 对象实际下载并tar tzf通过。