拓冰网站定制 
欢迎加入开源鸿蒙PC社区 https://harmonypc.csdn.net/欢迎在PC社区平台申请新建项目https://atomgit.com/OpenHarmonyPCDeveloper鸿蒙PC移植libadwaita1.8.8无显示测试实录元信息值对象libadwaita 1.8.8GNOME Adwaita UI 组件库C 原生环境HUAWEI MateBook ProHAD-W32/ HarmonyOS 6.1.0 / aarch64uname -m实测/ clang 15 / 社区适配版 Conan 2.29.1仓库build_in_harmonyosAtomGitOpenHarmonyPCDeveloper/build_in_harmonyosPR#13574目录摘要一、背景为什么值得做二、环境与差异前置9 个差异点先列全三、适配过程10 个坑四段式全记录四、验证分层禁止相加五、知识沉淀4 条草稿六、FAQ七、总结参考链接摘要把 GNOME 的 Adwaita UI 组件库libadwaita 1.8.8移植到鸿蒙 PCaarch641 个 portability 补丁、10 个适配问题、9 项依赖解析。上游 63/63 测试实跑全部因无显示服务阻塞SIGTRAP全量证据链入仓可复现其中 2 项纯计算测试的105/105 公共 API 断言 1:1 移植执行全部通过消费者探针124/124 全过。PR #13574 已合入 main沉淀 4 条知识草稿。libadwaita 是纯 UI 组件库它的核心 APIwidget、样式、动画全部预设了显示服务器的存在而鸿蒙 PC 目前没有显示服务。让它编译通过只花了约 7 分钟——真正的难点在于在一个没有显示器的环境里建立分层测试证据链——上游 63 个测试哪些能执行、哪些断言可以移植、如何证明能验证的全验证了、不能验证的写清楚了。本文是这条证据链的完整实录包括 2 处我自己走错路的误判。诚实声明以下内容在本环境中未验证本文不写成验证通过① 61 个创建 widget 的上游测试无显示服务SIGTRAP 阻塞② 137 条nearest_from_rgba断言私有 API库未导出该符号③ 一切视觉渲染效果无显示设备。本文结论限定于无显示 API 子集与可移植断言子集两个边界之内。一、背景为什么值得做libadwaita 是 GNOME 42 的默认 UI 组件库整个 GTK4 应用生态的视觉底座——GNOME 45 桌面应用的控件、主题、动画系统直接构建在它之上。它在本仓库生态链中的位置是承上启下的关键一环生态价值基础库下游受益面大。libadwaita 就位后GTK4 应用层含 C 绑定 gtkmm才有完整的视觉组件依赖补链价值本仓库此前已适配其 C 绑定 gtkmm 4.0.0.1无显示 API 探针方法论知识条目 E471正是在那次任务中诞生的C 原生核心库缺位等于 GNOME 桌面链断在中间难度价值无显示服务这一平台缺口迫使测试策略整体重设计——不是跑上游测试集这么简单而是要回答上游测试集里到底哪部分属于消费者可验证的范围。二、环境与差异前置2.1 环境项值设备HUAWEI MateBook ProHAD-W32系统HarmonyOS 6.1.0架构aarch64uname -m实测conan profilearcharmv8交叉印证工具链clang 15conan MesonToolchainlibc构建工具社区适配版 Conan 2.29.1OHOS 枚举/三元组已适配 build_in_harmonyos上游源https://download.gnome.org/sources/libadwaita/1.8/libadwaita-1.8.8.tar.xzSHA-2569e64939959a071cb660090c0e1b380c51ca29e3cfb57f3f23ea42a9922eb6f41构建规模meson 535 目标clean-room 全量约 7 分钟2.2 差异点先列全逐个在第三节展开#差异点上游假设鸿蒙 PC 实际情况1显示服务Wayland/X11 显示服务器存在无显示服务GTK4 仅 Broadway 后端可用broadwayd 受签名约束不可运行2GLib 版本测试代码用 2.86 APIg_log_get_always_fatal制品仓 glib/2.84.0.1.1只有 2.80 的 setter3glib .pc 完整性glib-2.0.pc自带-lintlPkgConfigDeps 生成只有-lglib-2.01.8.x 新代码直调g_libintl_*--no-undefined下必炸4glib 二进制工具系统工具可直接执行裸 2.84.0.1 包的工具未签名OHOS 上 “Operation not permitted”须用 .1.1已签名5依赖版本图appstream 钉 pango/1.50.14 zstd/1.5.7.1与 gtk4 链pango/1.56.4 zstd/1.5.7不可共存的版本冲突6组件键引用各配方组件键写法一致libxmlb 以无::gobject后缀键引用 glib 组件7appstream 获取subproject 源码 clone 可兜底1.8.x 起为 required 依赖离线 clone 必败8符号可见性测试可用库的全部符号测试链接内部静态库可用私有 API消费者只能链接 .so 导出面9构建缓存单用户干净缓存同机多任务共享 conan 缓存存在陈旧产物污染风险三、适配过程3.1 侦察动手前需要检查的三项依赖发布检查W0对依赖链顶层逐个conan download --only-recipe探测制品仓——gtk4/4.22.4、glib/2.84.0.1.1、appstream/1.2.0 均已发布依赖链不断裂可开工构建系统识别mesonGNOME 标准族交叉注意点是它的dependency()→ pkg-config 解析链和 subproject fallback 行为测试策略清点tests/meson.build的test_names63 项其中绝大多数创建 widget。策略定为全量构建 全量实跑 证据留档 纯计算子集断言移植——先把 63 个测试二进制全部编出来、全部跑一遍留证再谈移植。3.2 依赖树libadwaita/1.8.8meson535 目标 ├── gtk4/4.22.4 主依赖transitive_headers/libsBroadway-only 后端 │ └── 图内固定 pango/1.56.4、zstd/1.5.7、zlib/1.3.1.1、fontconfig/2.18.1.1 ├── glib/2.84.0.1.1 shared overridebin 工具已签名OHOS 可执行 ├── appstream/1.2.0 1.8.x 新增 required必须产出 .pc阻断 subproject clone │ └── libxmlb/0.3.19 以无后缀键引用 glib 组件 → 键别名注入 ├── pango/1.56.4 overrideSONAME libpango-1.0.so.0 兼容 1.50.14 链接 ├── zstd/1.5.7 overrideSONAME libzstd.so.1 兼容 1.5.7.1 链接 ├── fribidi/1.0.16 文本双向算法 └── sassc/3.6.2 build-time样式编译3.3 坑 1pango/zstd 双版本冲突对应差异 #5现象conan create直接报版本冲突——appstream/1.2.0 配方钉 pango/1.50.14 zstd/1.5.7.1compose/vips 链gtk4/4.22.4 链钉 pango/1.56.4 zstd/1.5.7meson 要求 pango ≥ 1.56两图不可共存。定位对比两份配方的 requires 钉住版本确认冲突是两个已发布配方各钉各的不是本包写错。方案主配方self.requires(pango/1.56.4, overrideTrue)zstd/1.5.7override统一图到 gtk4 链不降版本——libadwaita 1.8 的 meson 硬性要求 pango ≥ 1.56。经验override 前必须先确认预编译二进制的运行期符号。appstream 预编译包链接的是 1.50.14/1.5.7.1之所以能跑在 1.56.4/1.5.7 上是因为 pango 1.x 保持libpango-1.0.so.0、zstd 1.x 保持libzstd.so.1的 SONAME。先查 SONAME 再 override顺序反了就是埋雷。3.4 坑 2glib 组件键冲突对应差异 #6现象meson 依赖解析失败——appstream 的传递依赖 libxmlb/0.3.19 以无::gobject后缀的键引用 glib 组件而 conan 组件模型里只有带后缀的键。定位顺着报错找到 libxmlb 配方里glib无后缀键的引用点这是传递依赖的键写法和当前 conan 组件模型不一致不是 libadwaita 的问题。方案主配方generate()注入 4 组键别名glib::gobject→glib、glib::gmodule、glib::gthread、glib::giotest_package 同款注入消费者侧同样要解析这个图。经验传递依赖引用另一种写法的组件键时修复点在当前主配方的 generate()图的所有权在这里不要去改上游配方。3.5 坑 3g_libintl_*链接失败对应差异 #3现象链接阶段undefined reference to g_libintl_dngettextmeson 对库链接带--no-undefined一个都藏不住。定位nm -D查 glib 包——libintl.so.8 里有 12 个 T文本定义的g_libintl_*符号再查源码——1.8.x 新增的 adw-main.c / adw-tab-overview.c 直调g_libintl_dngettext1.2.0 没有这些直调所以旧版本幸免。根因是 PkgConfigDeps 生成的 glib-2.0.pc 的 Libs 只有-lglib-2.0缺-lintl。方案_normalize_glib_pc()——在 PkgConfigDeps 之后强制回写 6 个 glib 系 .pcprefix 统一指向 glib/2.84.0.1.1 包目录glib-2.0.pc 的 Libs 补-lintl。glib 包自带 libintl.so.8自洽闭环不引入外部 libintl。经验PkgConfigDeps 产出的 .pc 是按 conan 组件模型生成的不一定等于上游 .pc 的完整 Libs。先 nm 目标包的真实符号面再决定 .pc 要补什么——这是本包所有 .pc 修改的统一方法论。3.6 坑 4g_log_get_always_fatal()链接错误对应差异 #2现象两个测试二进制test-flap / test-preferences-window链接失败g_log_get_always_fatal未定义。定位该 getter 是 GLib 2.86 才有的符号ohpcd 的 glib/2.84.0.1.1 只有g_log_set_always_fatal2.80稳定 ABIsetter 内部强制| G_LOG_LEVEL_ERROR并返回旧 mask。方案唯一补丁0001-tests-ignore-deprecations.h.patchportability5/-1测试辅助头里改用 setter 并捕获返回值作为旧基线与上游抑制 ERROR-fatal 再恢复语义等价。0 处平台宏不是#ifdef __OHOS__分支是版本兼容。经验API 版本差只影响测试代码时用 portability 补丁修测试文件不动主库——补丁面最小、语义可对照、评审可核。3.7 坑 5GdkRGBA 成员名20 个编译错误现象消费者测试一次报 20 个编译错误——GdkRGBA没有.r/.g/.b/.a成员。定位读 gtk4 头文件的结构体定义成员名是.red/.green/.blue/.alpha。方案改成员名纯笔误级20 个错误同源。经验GTK4 相对 GTK3 的类型命名变化点成员名、API 更名要在写消费者测试前翻一次头文件确认别按 GTK3 的肌肉记忆写。3.8 坑 6easing 端点断言失败容差对齐不是放宽现象探针 B 段easing 端点检查2 条断言失败ease_in_elastic(0)与 0 偏差 -4.88e-4ease_in_out_elastic(0)偏差 8.48e-5。定位把上游 adw-easing.c 的 elastic 族公式代 t0 手算——该族公式没有 t0 特判端点值数学上就不是精确 0。再翻上游自己的 tests/test-easing.c断言写法是g_assert_cmpfloat_with_epsilon(..., 0, 0.005)——上游自己的容差就是 0.005。方案探针端点容差对齐上游契约 0.005。强调一下这不是把测试改松是和上游用同一把尺子——如果库的端点偏差超过 0.005上游自己的测试同样会挂。经验测试失败先查上游自己的断言容差/契约与上游同源比自己放宽在评审上站得住得多。3.9 坑 7探针 SIGSEGV——误判自曝①现象探针 D 段spring 物理参数崩溃SIGSEGVfault 0x1崩溃点在g_object_run_dispose内部。误判自曝第一反应是怀疑 gobject 链或平台内存子系统有问题——毕竟释放一个对象就崩很像环境损坏。这个方向查了半天没有新证据。纠正停手做对照组实验——D0/D1 用真正的 GObjectg_object_new创建、g_object_unref释放走完全相同的释放路径全部正常。对照成立说明 glib/gobject 链本身健康问题在测试代码自己AdwSpringParams是GBoxedG_DEFINE_BOXED_TYPE gatomicrefcount不是 GObject对它调用g_object_unref()是未定义行为——gobject 把这段内存当 GObject 解读内部字段被当弱引用 datalist 指针解引用fault 0x1 这种极低地址正是数据位模式被误读成指针的典型签名。方案改用adw_spring_params_unref(sp)。D 段 5 条断言damping_ratio/mass/stiffness/派生量 damping 2ζ√(mk) 20.0全过。经验① 写释放代码前先确认类型是 GObject / GBoxed / 裸 struct三者 unref 路径完全不同②“库坏了还是我写错了”对照组实验是最快的裁决方式——比继续读库源码便宜一个数量级。入档本案已入档知识草稿 E429错误签名SIGSEGV|g_object_run_dispose|fault 0x|GBoxed含对照组结论条目见第五节。3.10 坑 8.so 行为偏离源码——误判自曝②现象探针实测的 easing 值与源码公式手算对不上但源码 md5 一致、.so 反汇编与公式一致——“代码对、结果错”。误判自曝先怀疑源码被改过查 md5、怀疑编译产物异常反汇编逐条对公式——都排除了一度陷进平台浮点行为差异的假设里打转。纠正换个问题问自己——“运行的到底是不是我刚编出来的 .so”。一查 conan 缓存这台机器同机多任务共享缓存09-14 的旧会话残留了 libadwaita/1.8.8 的旧缓存条目旧 recipe revision / 旧源码conan 目录名哈希碰撞导致陈旧 build/package 目录被复用探针加载的是陈旧 .so。方案conan remove libadwaita/* -c全清 clean-room 重建实测值与公式完全一致。经验① 共享缓存机器上正式构建前先清本包旧条目② “反汇编一致但运行不一致这个签名第一嫌疑永远是实际加载的产物来源”而不是浮点/平台行为。入档本案已入档知识草稿 E430其中一条工具层细节特别值得注意——conan 不会重新校验已存在 source 目录的 sha256只校验下载时刻——这正是陈旧目录能被长期复用的工具层根因。3.11 坑 9appstream subproject 全源码 clone对应差异 #7现象meson setup 阶段开始 clone appstream 的全部源码离线环境必败且拖死构建。定位1.8.x 起 appstream 从可选变成required 依赖meson 里无required:false且带 subproject fallback——PkgConfigDeps 没产出 appstream.pcmeson 的dependency(appstream)就落到 fallback 分支去 clone。方案appstream/1.2.0 制品仓已发布PkgConfigDeps 产出 appstream.pc 后dependency()直接命中fallback 被阻断。经验meson 的 subproject fallback 是个静默陷阱——它不报错只是开始下载。GNOME 系配方里凡看到构建阶段出现 git clone先查哪个dependency()没被 .pc 满足。3.12 坑 10gtk_doc选项 deprecated现象meson 配置报gtk_doc选项错误。定位1.8 起该选项 deprecated查 meson_options.txt 确认替代项。方案-Ddocumentationfalse本任务不产出文档。经验GNOME 系构建选项随大版本轮换选项报错先翻meson_options.txt不要凭旧版本记忆传参。3.13 构建结果10 个坑清完后conan create全流程conan create archives/l/libadwaita/1.8.8/conanfile.py--buildmissing → meson535目标含全部63个上游测试二进制0 FAILED约7分钟clean-room → test_package: libadwaita-1.8.8 no-display probe:checks124PASS(105/105 upstream-ported assertions included)→ 产物libadwaita-1.so、libadwaita-1-internal.a、85 个头文件OHOS 签名图1真机 conan create 完整构建 消费者测试全过证明配方在真机环境可构建、124/124 全过不能证明下游可消费性、视觉渲染四、验证分层禁止相加口径声明下面 5 层分别统计、分别陈述不做任何相加或合并。“63 实跑”、“105 移植”、124 消费者是三个不同口径的数字混在一起说就是造假。4.1 上游测试实跑R51 三步法台账清点tests/meson.build的test_names列表 63 项全部构建成功535 目标 0 FAILED实跑63/63执行envGSETTINGS_BACKENDmemory GTK_A11Ynone每测试 10s 超时通过0失败模式63/63 同因非断言失败gtk_test_init → gtk_init → Gtk-WARNING: Failed to open display → g_log fatal → __builtin_trap() → SIGTRAPrc-5注意不是 exit 1分类63 项中61 项创建 widgetdisplay 依赖无显示服务下无法执行2 项纯计算test-easing / test-accent-color见 4.2/4.3次要环境问题非致命如实记录Fontconfig error: Cannot load default config file: File not found——fontconfig/2.18.1.1 包缺默认 fonts.conf显示链路可用前需处理证据已入仓可复现archives/l/libadwaita/1.8.8/upstream-tests/——summary.txt63 行一行一测试rc 首行关键输出 63 份 .out 全量原始输出 run-upstream-tests.py 复现 runner README.md。runner 对任意含build-release/tests/的构建目录一条命令重跑找不到测试二进制时报错退出exit 1不会静默空跑。4.2 断言 1:1 移植执行可移植子集 公共 API 断言63 项里只有 2 项是纯计算测试无 widget、无显示依赖它们的公共 API 断言已逐条移植到消费者测试test_package/test.c中无显示执行上游测试断言构成移植执行结果test-easing35 个 AdwEasing 值 × f(0)≈0 / f(1)≈1共70条70/70 PASStest-accent-colorto_rgba 精确 hex 9 to_standalone_rgba 18 rgba_to_standalone 8共35条35/35 PASS合计105条公共 API 断言105/105100%PASS移植是断言级 1:1数值、容差、判定方向逐条对照上游源文件test.c 内每条断言注释了上游行号例如 easing 端点/* 上游 test-easing.cg_assert_cmpfloat_with_epsilon (adw_easing_ease (e, 0), 0, 0.005) */okcheck(fabs(adw_easing_ease(e,0.0))0.005,easing f(0)~0 (eps 0.005));口径边界这里比较重要这是上游测试的公共 API断言在无显示环境被执行不是上游测试二进制被执行那些二进制因 gtk_test_init 前置 display 初始化而无法启动。两个口径在本文和 PR 里始终分开陈述。4.3 私有 API 137 条分类留证不冒充移植上游 test-accent-color.c 另有137 条断言nearest_from_rgba roundtrip 10 各桌面调色板 127调用adw_accent_color_nearest_from_rgba()。这个函数仅声明于私有头src/adw-accent-color-private.h公共头 adwaita/ 目录无此声明未从 libadwaita-1.so 导出——nm -D --defined-only libadwaita-1.so.0 | grep nearest输出为空同一编译单元里的兄弟函数to_rgba / to_standalone_rgba / rgba_to_standalone均正常导出上游测试二进制之所以能用它meson 把 tests 链接到内部静态库libadwaita-1-internal.a全部符号、无可见性过滤。因此这 137 条消费者上下文不可执行消费者只能链接已安装的 .so。处理不入移植数字、不做通过声明按私有 API 子集分类留证函数名 私有头路径 nm -D 证据 上游可用的原因随 63/63 台账一并入仓。为什么不让测试去链接内部 .a那不是真实消费场景且内部 .a 的符号面不代表公共接口——那样做会让测试通过的声明失真。4.4 消费者测试124 checkstest_package/test.c 共124 项 checksok 累积决定进程退出码任一项失败即非零退出CI 可拦截段内容数量级别A版本/初始化态adw_get_major/minor/micro_version、版本宏、ADW_CHECK_VERSION 正/反、adw_is_initialized()FALSE7L1Beasing上游 1:1 移植 70 解析值/单调性扩展 777L2Caccent-color上游 1:1 移植公共 API3535L2Dspring 物理参数new damping_ratio/mass/stiffness 派生量 damping 2ζ√(mk) 20.0GBoxedadw_spring_params_unref 释放5L2实测输出libadwaita-1.8.8 no-display probe: checks124 PASS (105/105 upstream-ported assertions included)L1/L2 声明A 段版本断言属 L1 级别单独不能宣称功能完成实质功能验证由 B/C/D 段承担真实 API 数值结果断言L2。D 段的2ζ√(mk)是 spring 模型的物理定义式属于结果断言而非能跑就算。图2消费者测试二进制直接运行证明交付物可独立执行且 124/124 全过不能证明功能面完整、视觉渲染4.5 产物核验项结果构建目标meson 535 目标 0 FAILED含 63 个上游测试二进制库产物libadwaita-1.so动态、libadwaita-1-internal.a内部静态供上游测试链接头文件85 个公共 API 面符号面nm -D核验公共 API 符号齐全私有 API如 nearest_from_rgba不导出4.3 的实证基础签名OHOS 共享库签名配方_sign_shared_libs构建耗时clean-room 全量约 7 分钟warm 缓存包命中、仅重编测试约 2 分钟4.6 CI 与评审完整轮次记录以及失败轮轮次构建号head结果说明1#638223bdd8cc9✅ 通过conan-build-test / L0 / L1 全绿2#638934b021501c⚠️ 作废worker CI-021 OOMzsh:1: fork failed: out of memory连git --version都 fork 不出——基础设施故障与代码无关重触发3#63909aed5e885✅ 通过重触发后全绿换 worker4#6640385273d54✅ 通过测试强化提交124 checks 证据链入仓后全绿检视记录平台 AI 检视曾多次基础设施故障“审查未能完成”另做了一轮本地 deep reviewcorrectness/security/performance/tests_contracts 四维度9 条发现P2×3 P3×6全部处置——runner 参数化 空跑保护exit 1、README 复现命令修正、test.c include 显式化检视报告已发 PR 讨论区。合并PR #13574 经评审Clancy_Xie批准合入 main关联 Issue #3562【高难度挑战】候选申请自动关闭。图3PR #13574 已合并页4.7 复现速查以下 3 条命令可在同环境复现本文全部核心数字命令 1、2 于本文发布前一日复核可运行实跑 env 由 runner 内部固定为实测值cd仓库根目录 build_in_harmonyos# 1) 全量构建 消费者测试期望 checks124 PASSOk: 1 / Fail: 0conan create archives/l/libadwaita/1.8.8--buildmissing# 2) 复跑上游 63/63 全量证据链BUILD_DIR 为含 build-release/tests/ 的 conan 构建根目录runner 找不到测试二进制时以非零码退出不会静默空跑python3 archives/l/libadwaita/1.8.8/upstream-tests/run-upstream-tests.pyBUILD_DIR# 3) 符号面核验期望输出为空私有符号未导出4.3 的 137 条分类依据nm-D--defined-only已安装 libadwaita 包目录/lib/libadwaita-1.so.0|grepnearest口径对应命令 1 → 3.13/4.4124命令 2 → 4.163/63命令 3 → 4.3137 分类。读者可尝试复现emm。。五、知识沉淀4 条草稿随 PR 入仓编号知识来源坑位复用价值E429对 GBoxed 调用 g_object_unref 致 SIGSEGV——类型混淆易被误判为 gobject 链损坏对照组实验是裁决手段坑 7所有 GLib 系 C 库的探针编写GObject/GBoxed 判别E430共享 conan 缓存陈旧 .so 污染——反汇编一致但运行不一致先查实际加载产物来源clean-room 重建定案坑 8多任务并行共享缓存的所有构建环境E431PkgConfigDeps 生成的 glib-2.0.pc 缺 -lintl 致 g_libintl_* 链接失败–no-undefined先 nm 目标包真实符号面再补 .pc坑 3所有依赖 glib 且代码直调 intl 函数的包E432上游测试链接内部静态库可用私有符号——消费者移植测试断言前须先nm -D过滤已导出符号公私二分如实申报4.3 节所有上游测试可用、公共 API 不可用符号的移植场景GNOME/GTK 系普遍存在 private 头草稿状态说明4 条均为.kv .md配套草稿随 PR 入仓、待主编 promote 为正式条目走草稿→审核→正式知识生命周期编号 E429-E432 与正式库无冲突graph validate 通过。六、FAQQ1上游 63 个测试 0 通过合理吗合理且已证明是平台阻塞而非断言失败63/63 同因 SIGTRAPgtk_init “Failed to open display”rc-5trap 信号不是 exit 1断言失败退出码。全量证据链已入仓summary.txt 63 份 .out 复现 runner任何人可在同类环境一条命令复跑。0/0 没跑和63/63 全跑了但被平台卡死是两回事——本文是后者。Q2105/105 移植断言算上游测试通过吗不算本文从不这样声称。准确口径上游 2 项纯计算测试的公共 API 断言子集在消费者上下文 1:1 执行通过。上游测试二进制本身因 display 前置初始化无法启动见 4.1。两个口径全文分开陈述PR 与 Issue 同口径。Q3137 条私有 API 断言为什么不想办法跑一下技术上可以链接内部 .a但那是伪消费场景内部 .a 的符号面不代表公共接口消费者拿不到它。跑了也只能证明内部实现如此不能证明库对消费者可用。如实分类留证4.3。Q4124 项消费者 checks 是不是空壳测试print 一下就算过不是。判定标准B/C/D 段是真实 API 调用 数值结果断言easing 数学值、颜色 hex 精确值、spring 物理定义式 2ζ√(mk)20.0任何一条数值不对进程即非零退出ok 累积CI 可拦截——这是 L2 级验证。A 段版本断言是 L1 级已单独声明不能宣称功能完成。test.c 全文在 PR 中可逐行复核。Q5libadwaita 是 UI 库核心不是渲染吗没验证渲染算适配完成吗不算渲染完成本文也这么写诚实声明。当前可用面 无显示 API 子集版本/easing 数学/颜色换算/spring 物理参数已验证 124/124widget 渲染属显示链路可用后的下一阶段届时上游 63 测试全集 视觉走查覆盖。配方层面依赖解析/构建/产物/签名/消费者链接已完整这是库已就位、渲染待显示服务的明确分界而非验证通过的模糊声明。七、总结7.1 量化盘点维度数字补丁1 个portability5/-10 处平台宏适配问题10 个含 2 处误判纠正对照组排除法 / 缓存污染 clean-room依赖解析9 项3 组 override 组件键别名 .pc 回写 subproject 阻断构建meson 535 目标 0 FAILED约 7 分钟clean-room上游测试63 清点 / 63 实跑 / 0 通过63/63 display 阻塞 SIGTRAP证据链入仓断言移植105/105 公共 API 断言 1:1 移植执行全过70 35私有 API137 条分类留证nm -D 实证不冒充移植消费者测试124/124 checksL1×7 L2×117知识沉淀4 条草稿E429-E432CI4 轮3 绿 1 基础设施故障作废PR 已合入 main7.2 可复用方法4 条display 依赖测试的三级分类 nm -D 第一闸上游测试先分 display 依赖 / 纯计算-公共 API / 纯计算-私有 API 三级移植前nm -D过滤导出符号公私二分如实申报本文 63 61 70/105 口径 137 留证与上游契约对齐的容差原则测试失败先翻上游自己的断言容差本文 eps 0.005 同源同源比放宽可辩护对照组裁决法崩溃/异常先建最小对照组真 GObject vs 疑点类型、新构建 vs 缓存产物再决定查库还是查自己——两处误判都是靠它止损的R51 证据链入仓测试台账 清点 实跑 逐项原始输出 可复现 runner全部进仓库——评审看到的不是我说 63/63是63 份 .out 在仓里。7.3 流程 checklist无显示 UI 库适配通用依赖发布检查conan download 逐个探测再动手清点上游测试清单预判 display 依赖占比定实跑 证据 移植策略.pc 修改前先 nm 目标包真实符号面消费者测试分 L1/L2 级L1 段带不能宣称功能完成声明上游证据链.out 全量 runner入仓参考链接PR已合并https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/13574Issue已关闭https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/issues/3562仓库https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos上游源码https://mirror.nju.edu.cn/gnome/sources/libadwaita/1.8/libadwaita-1.8.8.tar.xz 鸿蒙PC移植libadwaita1.8.8：从编译到合入实录
欢迎加入开源鸿蒙PC社区 https://harmonypc.csdn.net/欢迎在PC社区平台申请新建项目https://atomgit.com/OpenHarmonyPCDeveloper鸿蒙PC移植libadwaita1.8.8无显示测试实录元信息值对象libadwaita 1.8.8GNOME Adwaita UI 组件库C 原生环境HUAWEI MateBook ProHAD-W32/ HarmonyOS 6.1.0 / aarch64uname -m实测/ clang 15 / 社区适配版 Conan 2.29.1仓库build_in_harmonyosAtomGitOpenHarmonyPCDeveloper/build_in_harmonyosPR#13574目录摘要一、背景为什么值得做二、环境与差异前置9 个差异点先列全三、适配过程10 个坑四段式全记录四、验证分层禁止相加五、知识沉淀4 条草稿六、FAQ七、总结参考链接摘要把 GNOME 的 Adwaita UI 组件库libadwaita 1.8.8移植到鸿蒙 PCaarch641 个 portability 补丁、10 个适配问题、9 项依赖解析。上游 63/63 测试实跑全部因无显示服务阻塞SIGTRAP全量证据链入仓可复现其中 2 项纯计算测试的105/105 公共 API 断言 1:1 移植执行全部通过消费者探针124/124 全过。PR #13574 已合入 main沉淀 4 条知识草稿。libadwaita 是纯 UI 组件库它的核心 APIwidget、样式、动画全部预设了显示服务器的存在而鸿蒙 PC 目前没有显示服务。让它编译通过只花了约 7 分钟——真正的难点在于在一个没有显示器的环境里建立分层测试证据链——上游 63 个测试哪些能执行、哪些断言可以移植、如何证明能验证的全验证了、不能验证的写清楚了。本文是这条证据链的完整实录包括 2 处我自己走错路的误判。诚实声明以下内容在本环境中未验证本文不写成验证通过① 61 个创建 widget 的上游测试无显示服务SIGTRAP 阻塞② 137 条nearest_from_rgba断言私有 API库未导出该符号③ 一切视觉渲染效果无显示设备。本文结论限定于无显示 API 子集与可移植断言子集两个边界之内。一、背景为什么值得做libadwaita 是 GNOME 42 的默认 UI 组件库整个 GTK4 应用生态的视觉底座——GNOME 45 桌面应用的控件、主题、动画系统直接构建在它之上。它在本仓库生态链中的位置是承上启下的关键一环生态价值基础库下游受益面大。libadwaita 就位后GTK4 应用层含 C 绑定 gtkmm才有完整的视觉组件依赖补链价值本仓库此前已适配其 C 绑定 gtkmm 4.0.0.1无显示 API 探针方法论知识条目 E471正是在那次任务中诞生的C 原生核心库缺位等于 GNOME 桌面链断在中间难度价值无显示服务这一平台缺口迫使测试策略整体重设计——不是跑上游测试集这么简单而是要回答上游测试集里到底哪部分属于消费者可验证的范围。二、环境与差异前置2.1 环境项值设备HUAWEI MateBook ProHAD-W32系统HarmonyOS 6.1.0架构aarch64uname -m实测conan profilearcharmv8交叉印证工具链clang 15conan MesonToolchainlibc构建工具社区适配版 Conan 2.29.1OHOS 枚举/三元组已适配 build_in_harmonyos上游源https://download.gnome.org/sources/libadwaita/1.8/libadwaita-1.8.8.tar.xzSHA-2569e64939959a071cb660090c0e1b380c51ca29e3cfb57f3f23ea42a9922eb6f41构建规模meson 535 目标clean-room 全量约 7 分钟2.2 差异点先列全逐个在第三节展开#差异点上游假设鸿蒙 PC 实际情况1显示服务Wayland/X11 显示服务器存在无显示服务GTK4 仅 Broadway 后端可用broadwayd 受签名约束不可运行2GLib 版本测试代码用 2.86 APIg_log_get_always_fatal制品仓 glib/2.84.0.1.1只有 2.80 的 setter3glib .pc 完整性glib-2.0.pc自带-lintlPkgConfigDeps 生成只有-lglib-2.01.8.x 新代码直调g_libintl_*--no-undefined下必炸4glib 二进制工具系统工具可直接执行裸 2.84.0.1 包的工具未签名OHOS 上 “Operation not permitted”须用 .1.1已签名5依赖版本图appstream 钉 pango/1.50.14 zstd/1.5.7.1与 gtk4 链pango/1.56.4 zstd/1.5.7不可共存的版本冲突6组件键引用各配方组件键写法一致libxmlb 以无::gobject后缀键引用 glib 组件7appstream 获取subproject 源码 clone 可兜底1.8.x 起为 required 依赖离线 clone 必败8符号可见性测试可用库的全部符号测试链接内部静态库可用私有 API消费者只能链接 .so 导出面9构建缓存单用户干净缓存同机多任务共享 conan 缓存存在陈旧产物污染风险三、适配过程3.1 侦察动手前需要检查的三项依赖发布检查W0对依赖链顶层逐个conan download --only-recipe探测制品仓——gtk4/4.22.4、glib/2.84.0.1.1、appstream/1.2.0 均已发布依赖链不断裂可开工构建系统识别mesonGNOME 标准族交叉注意点是它的dependency()→ pkg-config 解析链和 subproject fallback 行为测试策略清点tests/meson.build的test_names63 项其中绝大多数创建 widget。策略定为全量构建 全量实跑 证据留档 纯计算子集断言移植——先把 63 个测试二进制全部编出来、全部跑一遍留证再谈移植。3.2 依赖树libadwaita/1.8.8meson535 目标 ├── gtk4/4.22.4 主依赖transitive_headers/libsBroadway-only 后端 │ └── 图内固定 pango/1.56.4、zstd/1.5.7、zlib/1.3.1.1、fontconfig/2.18.1.1 ├── glib/2.84.0.1.1 shared overridebin 工具已签名OHOS 可执行 ├── appstream/1.2.0 1.8.x 新增 required必须产出 .pc阻断 subproject clone │ └── libxmlb/0.3.19 以无后缀键引用 glib 组件 → 键别名注入 ├── pango/1.56.4 overrideSONAME libpango-1.0.so.0 兼容 1.50.14 链接 ├── zstd/1.5.7 overrideSONAME libzstd.so.1 兼容 1.5.7.1 链接 ├── fribidi/1.0.16 文本双向算法 └── sassc/3.6.2 build-time样式编译3.3 坑 1pango/zstd 双版本冲突对应差异 #5现象conan create直接报版本冲突——appstream/1.2.0 配方钉 pango/1.50.14 zstd/1.5.7.1compose/vips 链gtk4/4.22.4 链钉 pango/1.56.4 zstd/1.5.7meson 要求 pango ≥ 1.56两图不可共存。定位对比两份配方的 requires 钉住版本确认冲突是两个已发布配方各钉各的不是本包写错。方案主配方self.requires(pango/1.56.4, overrideTrue)zstd/1.5.7override统一图到 gtk4 链不降版本——libadwaita 1.8 的 meson 硬性要求 pango ≥ 1.56。经验override 前必须先确认预编译二进制的运行期符号。appstream 预编译包链接的是 1.50.14/1.5.7.1之所以能跑在 1.56.4/1.5.7 上是因为 pango 1.x 保持libpango-1.0.so.0、zstd 1.x 保持libzstd.so.1的 SONAME。先查 SONAME 再 override顺序反了就是埋雷。3.4 坑 2glib 组件键冲突对应差异 #6现象meson 依赖解析失败——appstream 的传递依赖 libxmlb/0.3.19 以无::gobject后缀的键引用 glib 组件而 conan 组件模型里只有带后缀的键。定位顺着报错找到 libxmlb 配方里glib无后缀键的引用点这是传递依赖的键写法和当前 conan 组件模型不一致不是 libadwaita 的问题。方案主配方generate()注入 4 组键别名glib::gobject→glib、glib::gmodule、glib::gthread、glib::giotest_package 同款注入消费者侧同样要解析这个图。经验传递依赖引用另一种写法的组件键时修复点在当前主配方的 generate()图的所有权在这里不要去改上游配方。3.5 坑 3g_libintl_*链接失败对应差异 #3现象链接阶段undefined reference to g_libintl_dngettextmeson 对库链接带--no-undefined一个都藏不住。定位nm -D查 glib 包——libintl.so.8 里有 12 个 T文本定义的g_libintl_*符号再查源码——1.8.x 新增的 adw-main.c / adw-tab-overview.c 直调g_libintl_dngettext1.2.0 没有这些直调所以旧版本幸免。根因是 PkgConfigDeps 生成的 glib-2.0.pc 的 Libs 只有-lglib-2.0缺-lintl。方案_normalize_glib_pc()——在 PkgConfigDeps 之后强制回写 6 个 glib 系 .pcprefix 统一指向 glib/2.84.0.1.1 包目录glib-2.0.pc 的 Libs 补-lintl。glib 包自带 libintl.so.8自洽闭环不引入外部 libintl。经验PkgConfigDeps 产出的 .pc 是按 conan 组件模型生成的不一定等于上游 .pc 的完整 Libs。先 nm 目标包的真实符号面再决定 .pc 要补什么——这是本包所有 .pc 修改的统一方法论。3.6 坑 4g_log_get_always_fatal()链接错误对应差异 #2现象两个测试二进制test-flap / test-preferences-window链接失败g_log_get_always_fatal未定义。定位该 getter 是 GLib 2.86 才有的符号ohpcd 的 glib/2.84.0.1.1 只有g_log_set_always_fatal2.80稳定 ABIsetter 内部强制| G_LOG_LEVEL_ERROR并返回旧 mask。方案唯一补丁0001-tests-ignore-deprecations.h.patchportability5/-1测试辅助头里改用 setter 并捕获返回值作为旧基线与上游抑制 ERROR-fatal 再恢复语义等价。0 处平台宏不是#ifdef __OHOS__分支是版本兼容。经验API 版本差只影响测试代码时用 portability 补丁修测试文件不动主库——补丁面最小、语义可对照、评审可核。3.7 坑 5GdkRGBA 成员名20 个编译错误现象消费者测试一次报 20 个编译错误——GdkRGBA没有.r/.g/.b/.a成员。定位读 gtk4 头文件的结构体定义成员名是.red/.green/.blue/.alpha。方案改成员名纯笔误级20 个错误同源。经验GTK4 相对 GTK3 的类型命名变化点成员名、API 更名要在写消费者测试前翻一次头文件确认别按 GTK3 的肌肉记忆写。3.8 坑 6easing 端点断言失败容差对齐不是放宽现象探针 B 段easing 端点检查2 条断言失败ease_in_elastic(0)与 0 偏差 -4.88e-4ease_in_out_elastic(0)偏差 8.48e-5。定位把上游 adw-easing.c 的 elastic 族公式代 t0 手算——该族公式没有 t0 特判端点值数学上就不是精确 0。再翻上游自己的 tests/test-easing.c断言写法是g_assert_cmpfloat_with_epsilon(..., 0, 0.005)——上游自己的容差就是 0.005。方案探针端点容差对齐上游契约 0.005。强调一下这不是把测试改松是和上游用同一把尺子——如果库的端点偏差超过 0.005上游自己的测试同样会挂。经验测试失败先查上游自己的断言容差/契约与上游同源比自己放宽在评审上站得住得多。3.9 坑 7探针 SIGSEGV——误判自曝①现象探针 D 段spring 物理参数崩溃SIGSEGVfault 0x1崩溃点在g_object_run_dispose内部。误判自曝第一反应是怀疑 gobject 链或平台内存子系统有问题——毕竟释放一个对象就崩很像环境损坏。这个方向查了半天没有新证据。纠正停手做对照组实验——D0/D1 用真正的 GObjectg_object_new创建、g_object_unref释放走完全相同的释放路径全部正常。对照成立说明 glib/gobject 链本身健康问题在测试代码自己AdwSpringParams是GBoxedG_DEFINE_BOXED_TYPE gatomicrefcount不是 GObject对它调用g_object_unref()是未定义行为——gobject 把这段内存当 GObject 解读内部字段被当弱引用 datalist 指针解引用fault 0x1 这种极低地址正是数据位模式被误读成指针的典型签名。方案改用adw_spring_params_unref(sp)。D 段 5 条断言damping_ratio/mass/stiffness/派生量 damping 2ζ√(mk) 20.0全过。经验① 写释放代码前先确认类型是 GObject / GBoxed / 裸 struct三者 unref 路径完全不同②“库坏了还是我写错了”对照组实验是最快的裁决方式——比继续读库源码便宜一个数量级。入档本案已入档知识草稿 E429错误签名SIGSEGV|g_object_run_dispose|fault 0x|GBoxed含对照组结论条目见第五节。3.10 坑 8.so 行为偏离源码——误判自曝②现象探针实测的 easing 值与源码公式手算对不上但源码 md5 一致、.so 反汇编与公式一致——“代码对、结果错”。误判自曝先怀疑源码被改过查 md5、怀疑编译产物异常反汇编逐条对公式——都排除了一度陷进平台浮点行为差异的假设里打转。纠正换个问题问自己——“运行的到底是不是我刚编出来的 .so”。一查 conan 缓存这台机器同机多任务共享缓存09-14 的旧会话残留了 libadwaita/1.8.8 的旧缓存条目旧 recipe revision / 旧源码conan 目录名哈希碰撞导致陈旧 build/package 目录被复用探针加载的是陈旧 .so。方案conan remove libadwaita/* -c全清 clean-room 重建实测值与公式完全一致。经验① 共享缓存机器上正式构建前先清本包旧条目② “反汇编一致但运行不一致这个签名第一嫌疑永远是实际加载的产物来源”而不是浮点/平台行为。入档本案已入档知识草稿 E430其中一条工具层细节特别值得注意——conan 不会重新校验已存在 source 目录的 sha256只校验下载时刻——这正是陈旧目录能被长期复用的工具层根因。3.11 坑 9appstream subproject 全源码 clone对应差异 #7现象meson setup 阶段开始 clone appstream 的全部源码离线环境必败且拖死构建。定位1.8.x 起 appstream 从可选变成required 依赖meson 里无required:false且带 subproject fallback——PkgConfigDeps 没产出 appstream.pcmeson 的dependency(appstream)就落到 fallback 分支去 clone。方案appstream/1.2.0 制品仓已发布PkgConfigDeps 产出 appstream.pc 后dependency()直接命中fallback 被阻断。经验meson 的 subproject fallback 是个静默陷阱——它不报错只是开始下载。GNOME 系配方里凡看到构建阶段出现 git clone先查哪个dependency()没被 .pc 满足。3.12 坑 10gtk_doc选项 deprecated现象meson 配置报gtk_doc选项错误。定位1.8 起该选项 deprecated查 meson_options.txt 确认替代项。方案-Ddocumentationfalse本任务不产出文档。经验GNOME 系构建选项随大版本轮换选项报错先翻meson_options.txt不要凭旧版本记忆传参。3.13 构建结果10 个坑清完后conan create全流程conan create archives/l/libadwaita/1.8.8/conanfile.py--buildmissing → meson535目标含全部63个上游测试二进制0 FAILED约7分钟clean-room → test_package: libadwaita-1.8.8 no-display probe:checks124PASS(105/105 upstream-ported assertions included)→ 产物libadwaita-1.so、libadwaita-1-internal.a、85 个头文件OHOS 签名图1真机 conan create 完整构建 消费者测试全过证明配方在真机环境可构建、124/124 全过不能证明下游可消费性、视觉渲染四、验证分层禁止相加口径声明下面 5 层分别统计、分别陈述不做任何相加或合并。“63 实跑”、“105 移植”、124 消费者是三个不同口径的数字混在一起说就是造假。4.1 上游测试实跑R51 三步法台账清点tests/meson.build的test_names列表 63 项全部构建成功535 目标 0 FAILED实跑63/63执行envGSETTINGS_BACKENDmemory GTK_A11Ynone每测试 10s 超时通过0失败模式63/63 同因非断言失败gtk_test_init → gtk_init → Gtk-WARNING: Failed to open display → g_log fatal → __builtin_trap() → SIGTRAPrc-5注意不是 exit 1分类63 项中61 项创建 widgetdisplay 依赖无显示服务下无法执行2 项纯计算test-easing / test-accent-color见 4.2/4.3次要环境问题非致命如实记录Fontconfig error: Cannot load default config file: File not found——fontconfig/2.18.1.1 包缺默认 fonts.conf显示链路可用前需处理证据已入仓可复现archives/l/libadwaita/1.8.8/upstream-tests/——summary.txt63 行一行一测试rc 首行关键输出 63 份 .out 全量原始输出 run-upstream-tests.py 复现 runner README.md。runner 对任意含build-release/tests/的构建目录一条命令重跑找不到测试二进制时报错退出exit 1不会静默空跑。4.2 断言 1:1 移植执行可移植子集 公共 API 断言63 项里只有 2 项是纯计算测试无 widget、无显示依赖它们的公共 API 断言已逐条移植到消费者测试test_package/test.c中无显示执行上游测试断言构成移植执行结果test-easing35 个 AdwEasing 值 × f(0)≈0 / f(1)≈1共70条70/70 PASStest-accent-colorto_rgba 精确 hex 9 to_standalone_rgba 18 rgba_to_standalone 8共35条35/35 PASS合计105条公共 API 断言105/105100%PASS移植是断言级 1:1数值、容差、判定方向逐条对照上游源文件test.c 内每条断言注释了上游行号例如 easing 端点/* 上游 test-easing.cg_assert_cmpfloat_with_epsilon (adw_easing_ease (e, 0), 0, 0.005) */okcheck(fabs(adw_easing_ease(e,0.0))0.005,easing f(0)~0 (eps 0.005));口径边界这里比较重要这是上游测试的公共 API断言在无显示环境被执行不是上游测试二进制被执行那些二进制因 gtk_test_init 前置 display 初始化而无法启动。两个口径在本文和 PR 里始终分开陈述。4.3 私有 API 137 条分类留证不冒充移植上游 test-accent-color.c 另有137 条断言nearest_from_rgba roundtrip 10 各桌面调色板 127调用adw_accent_color_nearest_from_rgba()。这个函数仅声明于私有头src/adw-accent-color-private.h公共头 adwaita/ 目录无此声明未从 libadwaita-1.so 导出——nm -D --defined-only libadwaita-1.so.0 | grep nearest输出为空同一编译单元里的兄弟函数to_rgba / to_standalone_rgba / rgba_to_standalone均正常导出上游测试二进制之所以能用它meson 把 tests 链接到内部静态库libadwaita-1-internal.a全部符号、无可见性过滤。因此这 137 条消费者上下文不可执行消费者只能链接已安装的 .so。处理不入移植数字、不做通过声明按私有 API 子集分类留证函数名 私有头路径 nm -D 证据 上游可用的原因随 63/63 台账一并入仓。为什么不让测试去链接内部 .a那不是真实消费场景且内部 .a 的符号面不代表公共接口——那样做会让测试通过的声明失真。4.4 消费者测试124 checkstest_package/test.c 共124 项 checksok 累积决定进程退出码任一项失败即非零退出CI 可拦截段内容数量级别A版本/初始化态adw_get_major/minor/micro_version、版本宏、ADW_CHECK_VERSION 正/反、adw_is_initialized()FALSE7L1Beasing上游 1:1 移植 70 解析值/单调性扩展 777L2Caccent-color上游 1:1 移植公共 API3535L2Dspring 物理参数new damping_ratio/mass/stiffness 派生量 damping 2ζ√(mk) 20.0GBoxedadw_spring_params_unref 释放5L2实测输出libadwaita-1.8.8 no-display probe: checks124 PASS (105/105 upstream-ported assertions included)L1/L2 声明A 段版本断言属 L1 级别单独不能宣称功能完成实质功能验证由 B/C/D 段承担真实 API 数值结果断言L2。D 段的2ζ√(mk)是 spring 模型的物理定义式属于结果断言而非能跑就算。图2消费者测试二进制直接运行证明交付物可独立执行且 124/124 全过不能证明功能面完整、视觉渲染4.5 产物核验项结果构建目标meson 535 目标 0 FAILED含 63 个上游测试二进制库产物libadwaita-1.so动态、libadwaita-1-internal.a内部静态供上游测试链接头文件85 个公共 API 面符号面nm -D核验公共 API 符号齐全私有 API如 nearest_from_rgba不导出4.3 的实证基础签名OHOS 共享库签名配方_sign_shared_libs构建耗时clean-room 全量约 7 分钟warm 缓存包命中、仅重编测试约 2 分钟4.6 CI 与评审完整轮次记录以及失败轮轮次构建号head结果说明1#638223bdd8cc9✅ 通过conan-build-test / L0 / L1 全绿2#638934b021501c⚠️ 作废worker CI-021 OOMzsh:1: fork failed: out of memory连git --version都 fork 不出——基础设施故障与代码无关重触发3#63909aed5e885✅ 通过重触发后全绿换 worker4#6640385273d54✅ 通过测试强化提交124 checks 证据链入仓后全绿检视记录平台 AI 检视曾多次基础设施故障“审查未能完成”另做了一轮本地 deep reviewcorrectness/security/performance/tests_contracts 四维度9 条发现P2×3 P3×6全部处置——runner 参数化 空跑保护exit 1、README 复现命令修正、test.c include 显式化检视报告已发 PR 讨论区。合并PR #13574 经评审Clancy_Xie批准合入 main关联 Issue #3562【高难度挑战】候选申请自动关闭。图3PR #13574 已合并页4.7 复现速查以下 3 条命令可在同环境复现本文全部核心数字命令 1、2 于本文发布前一日复核可运行实跑 env 由 runner 内部固定为实测值cd仓库根目录 build_in_harmonyos# 1) 全量构建 消费者测试期望 checks124 PASSOk: 1 / Fail: 0conan create archives/l/libadwaita/1.8.8--buildmissing# 2) 复跑上游 63/63 全量证据链BUILD_DIR 为含 build-release/tests/ 的 conan 构建根目录runner 找不到测试二进制时以非零码退出不会静默空跑python3 archives/l/libadwaita/1.8.8/upstream-tests/run-upstream-tests.pyBUILD_DIR# 3) 符号面核验期望输出为空私有符号未导出4.3 的 137 条分类依据nm-D--defined-only已安装 libadwaita 包目录/lib/libadwaita-1.so.0|grepnearest口径对应命令 1 → 3.13/4.4124命令 2 → 4.163/63命令 3 → 4.3137 分类。读者可尝试复现emm。。五、知识沉淀4 条草稿随 PR 入仓编号知识来源坑位复用价值E429对 GBoxed 调用 g_object_unref 致 SIGSEGV——类型混淆易被误判为 gobject 链损坏对照组实验是裁决手段坑 7所有 GLib 系 C 库的探针编写GObject/GBoxed 判别E430共享 conan 缓存陈旧 .so 污染——反汇编一致但运行不一致先查实际加载产物来源clean-room 重建定案坑 8多任务并行共享缓存的所有构建环境E431PkgConfigDeps 生成的 glib-2.0.pc 缺 -lintl 致 g_libintl_* 链接失败–no-undefined先 nm 目标包真实符号面再补 .pc坑 3所有依赖 glib 且代码直调 intl 函数的包E432上游测试链接内部静态库可用私有符号——消费者移植测试断言前须先nm -D过滤已导出符号公私二分如实申报4.3 节所有上游测试可用、公共 API 不可用符号的移植场景GNOME/GTK 系普遍存在 private 头草稿状态说明4 条均为.kv .md配套草稿随 PR 入仓、待主编 promote 为正式条目走草稿→审核→正式知识生命周期编号 E429-E432 与正式库无冲突graph validate 通过。六、FAQQ1上游 63 个测试 0 通过合理吗合理且已证明是平台阻塞而非断言失败63/63 同因 SIGTRAPgtk_init “Failed to open display”rc-5trap 信号不是 exit 1断言失败退出码。全量证据链已入仓summary.txt 63 份 .out 复现 runner任何人可在同类环境一条命令复跑。0/0 没跑和63/63 全跑了但被平台卡死是两回事——本文是后者。Q2105/105 移植断言算上游测试通过吗不算本文从不这样声称。准确口径上游 2 项纯计算测试的公共 API 断言子集在消费者上下文 1:1 执行通过。上游测试二进制本身因 display 前置初始化无法启动见 4.1。两个口径全文分开陈述PR 与 Issue 同口径。Q3137 条私有 API 断言为什么不想办法跑一下技术上可以链接内部 .a但那是伪消费场景内部 .a 的符号面不代表公共接口消费者拿不到它。跑了也只能证明内部实现如此不能证明库对消费者可用。如实分类留证4.3。Q4124 项消费者 checks 是不是空壳测试print 一下就算过不是。判定标准B/C/D 段是真实 API 调用 数值结果断言easing 数学值、颜色 hex 精确值、spring 物理定义式 2ζ√(mk)20.0任何一条数值不对进程即非零退出ok 累积CI 可拦截——这是 L2 级验证。A 段版本断言是 L1 级已单独声明不能宣称功能完成。test.c 全文在 PR 中可逐行复核。Q5libadwaita 是 UI 库核心不是渲染吗没验证渲染算适配完成吗不算渲染完成本文也这么写诚实声明。当前可用面 无显示 API 子集版本/easing 数学/颜色换算/spring 物理参数已验证 124/124widget 渲染属显示链路可用后的下一阶段届时上游 63 测试全集 视觉走查覆盖。配方层面依赖解析/构建/产物/签名/消费者链接已完整这是库已就位、渲染待显示服务的明确分界而非验证通过的模糊声明。七、总结7.1 量化盘点维度数字补丁1 个portability5/-10 处平台宏适配问题10 个含 2 处误判纠正对照组排除法 / 缓存污染 clean-room依赖解析9 项3 组 override 组件键别名 .pc 回写 subproject 阻断构建meson 535 目标 0 FAILED约 7 分钟clean-room上游测试63 清点 / 63 实跑 / 0 通过63/63 display 阻塞 SIGTRAP证据链入仓断言移植105/105 公共 API 断言 1:1 移植执行全过70 35私有 API137 条分类留证nm -D 实证不冒充移植消费者测试124/124 checksL1×7 L2×117知识沉淀4 条草稿E429-E432CI4 轮3 绿 1 基础设施故障作废PR 已合入 main7.2 可复用方法4 条display 依赖测试的三级分类 nm -D 第一闸上游测试先分 display 依赖 / 纯计算-公共 API / 纯计算-私有 API 三级移植前nm -D过滤导出符号公私二分如实申报本文 63 61 70/105 口径 137 留证与上游契约对齐的容差原则测试失败先翻上游自己的断言容差本文 eps 0.005 同源同源比放宽可辩护对照组裁决法崩溃/异常先建最小对照组真 GObject vs 疑点类型、新构建 vs 缓存产物再决定查库还是查自己——两处误判都是靠它止损的R51 证据链入仓测试台账 清点 实跑 逐项原始输出 可复现 runner全部进仓库——评审看到的不是我说 63/63是63 份 .out 在仓里。7.3 流程 checklist无显示 UI 库适配通用依赖发布检查conan download 逐个探测再动手清点上游测试清单预判 display 依赖占比定实跑 证据 移植策略.pc 修改前先 nm 目标包真实符号面消费者测试分 L1/L2 级L1 段带不能宣称功能完成声明上游证据链.out 全量 runner入仓参考链接PR已合并https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/13574Issue已关闭https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/issues/3562仓库https://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos上游源码https://mirror.nju.edu.cn/gnome/sources/libadwaita/1.8/libadwaita-1.8.8.tar.xz