@hmos-library-adapter/fast 0.0.17-beta.1 → 0.0.17-beta.2

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E506.md

@@ -0,0 +1,47 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E506: Keep compiler-enabled NEON call sites aligned with CMake implementation sources
+
+> **严重度**: 🔴 blocking | **分类**: cmake, linking, arm-neon, source-selection | **自动修复**: ❌
+
+---
+
+## 错误特征
+
+```
+undefined symbol:.*png_.*_neon
+undefined reference to.*png_.*_neon
+```
+
+## 根因
+
+The target compiler enables NEON declarations and call sites while CMake relies only on a processor-name string, so unknown cross-system processor metadata omits the matching implementation sources.
+
+## 验证命令
+
+```bash
+Exercise known ARM, unknown processor with a passing intrinsic probe, unknown processor with a failing probe, and preserved Apple selection; then link the real target.
+```
+
+## 解决方案
+
+**compiler-capability-backed-neon-source-selection**：Preserve known platform selectors and append architecture implementation sources only when the target compiler can compile a real intrinsic probe; preserve a negative case that selects none.
+
+```bash
+Use CheckCSourceCompiles with arm_neon.h and a real intrinsic, then append all implementation files required by the enabled headers.
+```
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`CMAKE_SYSTEM_PROCESSOR.*unknown.*append|(__OHOS__|OHOS|HarmonyOS).*neon|ignore.*undefined.*png_.*_neon`
+- **原因**：An unknown processor string is not ARM evidence, a platform name is not a compiler capability, and suppressing link errors leaves call sites without implementations.
+- **后果**：Non-ARM targets compile ARM sources or ARM targets reach final link with missing NEON symbols.
+
+## 涉及软件
+
+Vendored or standalone libraries whose preprocessor enables architecture intrinsics independently from their CMake source-list selector.
+
+---
+*条目 E506 · 更新 2026-08-15 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E507.md

@@ -0,0 +1,51 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E507: Probe optional pthread cancellation state before enabling Boost sleep calls
+
+> **严重度**: 🔴 blocking | **分类**: cmake, boost, capability-detection, pthread | **自动修复**: ❌
+
+---
+
+## 错误特征
+
+```
+sp_thread_sleep.*pthread_setcancelstate
+pthread_setcancelstate.*undeclared
+```
+
+## 根因
+
+POSIX thread support does not guarantee the optional pthread cancellation-state API, while bundled Boost can infer its call path from BOOST_HAS_PTHREADS alone.
+
+## 验证命令
+
+```bash
+Configure and build twice with a link-aware pthread_setcancelstate probe forced absent and present; require the guard only in the absent build and scan out platform-name conditionals.
+```
+
+## 解决方案
+
+**link-aware-symbol-capability-selection**：Probe pthread_setcancelstate with Threads::Threads and apply BOOST_SP_THREAD_SLEEP_NO_PTHREAD_SETCANCELSTATE only to the target that embeds the Boost sleep implementation when the symbol is unavailable.
+
+```bash
+Use CheckCXXSymbolExists with CMAKE_REQUIRED_LIBRARIES=Threads::Threads, restore the probe state, and gate only the cancellation-state calls while retaining nanosleep.
+```
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`__OHOS__|HarmonyOS|pthread_setcancelstate.*stub`
+- **原因**：Platform-name branches and no-op pthread stubs misrepresent the target capability and can alter thread cancellation semantics.
+- **后果**：The adaptation becomes non-portable or silently changes runtime behavior.
+
+## 涉及软件
+
+CMake projects that embed Boost thread-sleep code on POSIX-capable targets without pthread_setcancelstate.
+
+## 相关模式
+
+- **相似模式**：[E127](E127.md)
+
+---
+*条目 E507 · 更新 2026-08-16 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E508.md

@@ -0,0 +1,68 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E508: glib libintl.h 将 gettext 宏定义为 g_libintl_*
+
+> **严重度**: 🔴 blocking | **分类**: platform, detection, linking | **自动修复**: ❌
+
+---
+
+## 错误特征
+
+```
+g_libintl_.*
+undefined symbol.*g_libintl
+host_machine.*harmonyos
+implicit declaration.*dgettext
+```
+
+## 根因
+
+glib libintl.h 将 gettext 宏定义为 g_libintl_*，OHOS musl
+libintl.so 只导出 libintl_* 符号，glib 静态库引用 g_libintl_*
+无定义 → 链接 undefined symbol；meson 报 host_machine=harmonyos
+不匹配 'linux' 条件分支，Linux 特有链接器选项被跳过。
+
+## 验证命令
+
+```bash
+pkg-config --modversion glib-2.0 && ninja -C builddir test
+```
+
+## 解决方案
+
+**intl-wrapper**：创建 intl-wrapper.c 将 g_libintl_* 符号映射到返回 msgid 的
+兜底实现（OHOS musl 单域），加入 meson.build 源文件列表，
+并注入 -Ddgettext(a,b)=((char*)(b)) 避 int 转换；
+同时 meson.build 的 host_machine.system() == 'linux' 改为
+in ['linux', 'harmonyos'] 使 Linux 特有链接器选项生效。
+
+```bash
+sed -i "s/if host_machine.system() == 'linux'/if host_machine.system() in ['linux', 'harmonyos']/g" meson.build && echo 'char *g_libintl_gettext(const char *m){return (char*)(m);}' > intl-wrapper.c
+```
+
+## 回退方案
+
+**pkg-config-propagation**：PkgConfigDeps 让 configure 通过 pkg-config 找到 glib，
+package_info() 声明 cpp_info.requires=["glib::glib"]，
+复制 glib 包子模块 .pc（gobject/gio/gmodule）。
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`-Ddgettext=.*libintl_dgettext`
+- **原因**：不要直接链接 libintl_dgettext（OHOS musl 无该导出），
+应走 g_libintl_* 兜底映射或返回 msgid
+- **后果**：链接期 undefined symbol，需额外 wrapper
+
+## 涉及软件
+
+所有依赖 glib 且用 meson 构建的 GNOME 生态库
+（atk/gtk+/pango 等，凡静态链接 glib 并引用 libintl 符号者）。
+
+## 相关模式
+
+- **相似模式**：[E090](E090.md)、[E107](E107.md)
+
+---
+*条目 E508 · 更新 2026-08-12 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E509.md

@@ -0,0 +1,97 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E509: harmonybrew 动态二进制依赖 OpenSSL 3.x 符号，系统旧版 libssl 缺符号
+
+> **严重度**: 🟡 medium | **分类**: musl, linking, security | **自动修复**: ❌
+
+---
+
+## 错误特征
+
+```
+Error relocating.*symbol not found
+OBJ_nid2sn.*symbol not found
+SSL_CTX_new.*symbol not found
+OSSL_PROVIDER_try_load.*symbol not found
+CRYPTO_malloc.*symbol not found
+```
+
+## 根因
+
+harmonybrew 提供的 cargo/rustc 等工具链二进制是动态链接 ELF，
+NEEDED 列表含 libssl.so/libcrypto.so。其 RUNPATH 指向
+harmonybrew openssl@3/lib（OpenSSL 3.6.3），但鸿蒙系统动态
+加载器在解析 RUNPATH 前可能已从 /usr/lib 或 /system/lib 加载
+了旧版 libssl.so.3（缺少 OBJ_nid2sn、SSL_CTX_new、
+OSSL_PROVIDER_try_load 等 OpenSSL 3.x 符号），导致
+"Error relocating cargo.real: symbol not found"。
+与 E078 不同：E078 是解释型语言扩展模块通过 dlopen 加载时
+BIND_NOW 导致 Python API 符号缺失；本条是原生动态二进制
+（cargo）的 RUNPATH 解析顺序问题，加载器优先用了系统旧版
+OpenSSL。
+
+## 验证命令
+
+```bash
+# 检查 cargo.real 的 NEEDED 与 RUNPATH
+readelf -d ~/.harmonybrew/Cellar/rust/1.97.1/bin/cargo.real | grep -E "NEEDED|RUNPATH"
+# 检查系统是否有旧版 libssl
+find /usr/lib /system/lib -name "libssl.so*" 2>/dev/null
+# 诊断：直接运行 cargo，若报 "Error relocating... symbol not found" 则命中 E258
+cargo --version 2>&1 | head -5
+```
+
+## 解决方案
+
+**set-LD_LIBRARY_PATH-to-harmonybrew-openssl**：在 conanfile.py build() 开头显式设置 LD_LIBRARY_PATH 指向
+harmonybrew 的 OpenSSL 3.6.3 库目录
+（~/.harmonybrew/opt/openssl@3/lib），强制动态加载器
+优先用 harmonybrew 的匹配版本，而非系统旧版 libssl.so.3。
+关键：RUNPATH 不可靠（加载器可能优先系统路径），必须用
+LD_LIBRARY_PATH 覆盖。
+
+```bash
+import os
+brew_lib = os.path.expanduser("~/.harmonybrew/opt/openssl@3/lib")
+if os.path.isdir(brew_lib):
+    existing = os.environ.get("LD_LIBRARY_PATH", "")
+    os.environ["LD_LIBRARY_PATH"] = brew_lib + (":" + existing if existing else "")
+    os.environ["DYLD_LIBRARY_PATH"] = os.environ["LD_LIBRARY_PATH"]
+```
+
+## 回退方案
+
+**static-link-cargo**：若 LD_LIBRARY_PATH 仍无法解决（如 harmonybrew OpenSSL
+版本也不匹配），考虑用 RUSTFLAGS 重新编译 cargo 为
+静态链接，消除对 libssl.so 的运行时依赖。
+
+```bash
+RUSTFLAGS="-C target-feature=+crt-static" cargo build --release
+```
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`删除.*RUNPATH|patchelf.*--remove-rpath`
+- **原因**：删除 RUNPATH 会让加载器完全依赖系统搜索路径，更容易命中旧版 libssl
+- **后果**：cargo 启动失败，报更多 symbol not found
+
+### 🚫 禁止 2
+
+- **模式**：`ln.*-sf.*system.*libssl.*harmonybrew`
+- **原因**：用系统旧版 libssl 软链接覆盖 harmonybrew 会让所有依赖 OpenSSL 3.x 的程序都缺符号
+- **后果**：harmonybrew 全局工具链失效
+
+## 涉及软件
+
+所有依赖 OpenSSL 3.x 动态符号的 harmonybrew 工具链二进制
+（cargo、rustc、curl-openssl 等），以及任何 RUNPATH 指向
+harmonybrew 但加载器优先用系统旧版库的场景
+
+## 相关模式
+
+- **相似模式**：[E078](E078.md)、[E019](E019.md)
+
+---
+*条目 E509 · 更新 2026-08-12 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E510.md

@@ -0,0 +1,95 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E510: toybox patch 无法处理带路径层级/fuzz 的上游补丁，需前置 harmonybrew GNU patch
+
+> **严重度**: 🟡 medium | **分类**: ohos, build-system, patch | **自动修复**: ❌
+
+---
+
+## 错误特征
+
+```
+Hunk.*FAILED
+patch.*succeeded.*with fuzz
+can't find file to patch
+does not exist in index
+```
+
+## 根因
+
+鸿蒙系统 /usr/bin/patch 或 /system/bin/patch 是 toybox 实现，
+缺少 GNU patch 的 fuzz tolerance（上下文偏移容差）和路径
+层级自动剥离能力。带 bundled C 补丁的 Rust crate（如
+libquickjs-sys 的 stack-overflow-signed.patch）的 hunks 上下文
+与 vendored 源码有偏移，toybox patch 直接报 "Hunk #1 FAILED"，
+而 GNU patch 能用 fuzz 2 容差成功应用（"Hunk #1 succeeded
+at 1587 with fuzz 2 (offset -145)"）。
+
+## 验证命令
+
+```bash
+# 检查系统 patch 是否为 toybox
+ls -la /usr/bin/patch /system/bin/patch 2>/dev/null
+/usr/bin/patch --version 2>&1 | head -2
+# 检查 harmonybrew GNU patch
+ls -la ~/.harmonybrew/bin/patch 2>/dev/null
+~/.harmonybrew/bin/patch --version 2>&1 | head -2
+```
+
+## 解决方案
+
+**prepend-harmonybrew-gnu-patch**：在 conanfile.py build() 开头将 harmonybrew 的 GNU patch
+（~/.harmonybrew/bin/patch）前置到 PATH，确保 cargo build
+调用 build script 中的 patch 命令时用 GNU patch 而非 toybox。
+若 harmonybrew 未安装 gpatch，先通过 brew install gpatch。
+
+```bash
+import os, shutil
+brew_bin = os.path.expanduser("~/.harmonybrew/bin")
+gpatch = os.path.join(brew_bin, "patch")
+if not (os.path.isfile(gpatch) and os.access(gpatch, os.X_OK)):
+    brew = os.path.join(brew_bin, "brew")
+    if os.path.isfile(brew):
+        self.run(f"{brew} install gpatch", env="conanbuild")
+if os.path.isfile(gpatch) and os.access(gpatch, os.X_OK):
+    os.environ["PATH"] = brew_bin + ":" + os.environ.get("PATH", "")
+```
+
+## 回退方案
+
+**pre-apply-patches-manually**：若 GNU patch 不可用，在 build() 前手动用 patch -p1
+应用 bundled 补丁，绕过 cargo build script 的自动
+补丁应用。
+
+```bash
+cd $BUILD_SRC_DIR
+for p in vendor/libquickjs-sys/patches/*.patch; do
+    /usr/bin/patch -p1 < "$p" || true
+done
+```
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`patch.*--no-fuzz|patch.*--fuzz=0`
+- **原因**：禁用 fuzz tolerance 会让带偏移上下文的补丁全部失败
+- **后果**：bundled C 补丁无法应用，cargo build 中断
+
+### 🚫 禁止 2
+
+- **模式**：`rm.*-f.*/usr/bin/patch|ln.*-sf.*gpatch.*/usr/bin/patch`
+- **原因**：替换系统 patch 会影响所有依赖 /usr/bin/patch 的程序
+- **后果**：系统级补丁工具失效，其他构建受影响
+
+## 涉及软件
+
+所有带 bundled C 补丁的 Rust crate（libquickjs-sys 等），
+以及任何需要 fuzz tolerance 或路径层级剥离的补丁应用场景
+
+## 相关模式
+
+- **相似模式**：[E043](E043.md)
+
+---
+*条目 E510 · 更新 2026-08-12 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E511.md

@@ -0,0 +1,73 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E511: HarmonyOS 上 Meson 版本化共享库软链接缺失
+
+> **严重度**: 🔴 blocking | **分类**: hmdfs, ohos, meson, packaging, symlink | **自动修复**: ✅ conan-recipe-helper | **原则**: [P016](../principles.md#P016)、[P017](../principles.md#P017)
+
+---
+
+## 错误特征
+
+```
+cannot find -l[^ ]+
+lib[^ ]+\.so(\.[0-9]+)? not found
+No such file or directory.*\.so
+failed to load.*\.so
+```
+
+## 根因
+
+Meson 以 libfoo.so.X.Y.Z 实体和 libfoo.so.X、libfoo.so 软链接发布共享库；HarmonyOS 目标文件系统可能拒绝创建或读取这些软链接，导致上游测试、链接器或运行时只看到版本化实体而无法按 ABI 或开发者库名解析。
+
+## 验证命令
+
+```bash
+find <build-or-package-dir> -type f -name 'lib*.so.*' ! -path '*.so.*.p/*' -print; ls -l <actual-lib-dir>/libfoo.so*
+```
+
+## 解决方案
+
+**materialize-versioned-so-aliases**：仅在 OHOS 上，于 meson.build() 后、meson.test() 前扫描实际 Meson 输出目录，并于 meson.install() 后扫描 package_folder/lib；对真实 libfoo.so.X.Y.Z 缺失时复制为 libfoo.so.X 与 libfoo.so，跳过 *.so.*.p 对象目录且不覆盖已有文件。
+
+```bash
+for each actual libfoo.so.X.Y.Z in build output and package lib: copy it to libfoo.so.X and libfoo.so only when those paths are absent
+```
+
+## 回退方案
+
+**use-static-library-when-supported**：若上游不支持可靠的共享库布局且使用方允许，可构建并验证静态库；这改变产物形态，不能替代需要共享 ABI 的包。
+
+```bash
+meson setup ... -Ddefault_library=static
+```
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`ln -s.*\.so|os\.symlink.*\.so`
+- **原因**：目标文件系统对符号链接存在已验证限制，继续创建链接会使构建或测试不稳定。
+- **后果**：上游测试或下游链接仍可能找不到 ABI 名称或开发者链接名。
+
+### 🚫 禁止 2
+
+- **模式**：`copy aliases only after meson install|package-only alias copy`
+- **原因**：Meson 上游测试在安装前从构建树执行，安装后才复制无法补齐该路径。
+- **后果**：包内文件完整但原生上游测试仍因库名解析失败。
+
+### 🚫 禁止 3
+
+- **模式**：`treat hardware backend failure as shared-library alias failure`
+- **原因**：文件别名只能解决库名解析，不能提供 usbfs、显示器或其他目标硬件能力。
+- **后果**：会把真实平台或硬件阻塞错误归因错误，并虚报测试覆盖。
+
+## 涉及软件
+
+在 HarmonyOS 原生构建并测试使用 Meson 生成版本化共享库的 Conan 配方；既影响 build tree 中的上游测试，也影响 package tree 中的下游链接和运行。
+
+## 相关模式
+
+- **相似模式**：[E316](E316.md)
+
+---
+*条目 E511 · 更新 2026-08-12 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E512.md

@@ -0,0 +1,39 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E512: 纯 Python 包 build() 自检 import 运行时 Python 包，宿主环境预装而 CI 干净环境缺失导致本地通过、远程 CI 失败
+
+> **严重度**: 🟡 medium | **分类**: python, dependency, ci-env | **自动修复**: ✅ pip-install-runtime-deps
+
+---
+
+## 错误特征
+
+```
+ModuleNotFoundError: No module named .unidecode.
+ModuleNotFoundError: No module named .*
+```
+
+## 根因
+
+纯 Python 包（无 C 扩展）的 build()/test_package 自检会 import 包内子模块，若子模块顶层 import 第三方运行时 Python 包（如 venc3.datastore -> unidecode），宿主开发环境预装该包时本地 conan create 通过，而 CI worker 为干净环境缺少该包，导致 conan-build-test 阶段 ModuleNotFoundError
+
+## 验证命令
+
+```bash
+python3 -c "import venc3.datastore" 2>&1 | tail -2; pip download unidecode pyyaml --no-deps -d ./dl 2>&1 | tail -2
+```
+
+## 解决方案
+
+**add-deps**：在 conanfile.py build() 与 test_package test() 的 pip install 中显式安装运行时 Python 包依赖（unidecode/pyyaml 等，社区源 pypi.cnb.cool 有 cp312-ohos_aarch64 预编译 wheel，先 pip download 验证可得性）；或在自检中跳过依赖外部包的子模块
+
+```bash
+pip download unidecode pyyaml --no-deps -d ./dl && conan create ...
+```
+
+## 涉及软件
+
+所有 build() 自检或 test_package 涉及第三方运行时 Python 包 import 的纯 Python 包 Conan 配方
+
+---
+*条目 E512 · 更新 2026-08-18 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E513.md

@@ -0,0 +1,64 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E513: Preserve joinable thread teardown when pthread cancellation is unavailable
+
+> **严重度**: 🟡 medium | **分类**: compat, libc, syscall, threading, lifecycle | **自动修复**: ❌ | **原则**: [P004](../principles.md#P004)、[P015](../principles.md#P015)
+
+---
+
+## 错误特征
+
+```
+pthread_cancel.*undeclared
+pthread_setcanceltype.*undeclared
+undefined reference to pthread_cancel
+undefined symbol: pthread_cancel
+```
+
+## 根因
+
+E085 identifies missing pthread cancellation APIs, but a no-op stub or simply returning an error changes the lifecycle of a joinable worker: callers still wait in pthread_join() and cannot reclaim the thread. A fallback must preserve both targeted exit and join semantics.
+
+## 验证命令
+
+```bash
+grep -R "pthread_cancel\\|pthread_setcanceltype\\|pthread_join" -n src posix common 2>/dev/null; nm -D <target-libc> | grep pthread_cancel || true
+```
+
+## 解决方案
+
+**guarded-signal-thread-exit**：Keep the normal pthread-cancel path when available; otherwise install a narrowly scoped async-signal-safe thread-exit handler before creating the joinable worker, send a reserved signal with pthread_kill(), and join the worker. Ensure the application's signal-mask setup does not block that reserved signal.
+
+```bash
+# project-specific: handler calls pthread_exit(0); fallback cancellation calls pthread_kill(thread, SIGUSR1); then pthread_join(thread, &status)
+```
+
+## 回退方案
+
+**cooperative-stop-and-join**：Prefer an existing project stop flag, condition-variable wakeup, or event-loop shutdown hook when the project cannot reserve a process-wide signal safely.
+
+## 🚫 禁止策略
+
+### 🚫 禁止 1
+
+- **模式**：`int pthread_cancel\(.*\).*return 0|stub.*pthread_cancel|define.*pthread_cancel.*return 0`
+- **原因**：A successful-looking cancellation stub leaves the worker running and lets code incorrectly proceed to pthread_join() or resource teardown.
+- **后果**：Hangs, leaked threads, use-after-free races, or a false claim that cancellation behavior was preserved.
+
+### 🚫 禁止 2
+
+- **模式**：`pthread_kill\([^,]+,\s*SIGUSR1\).*without.*sigaction|sigaddset\([^,]+,\s*SIGUSR1\)`
+- **原因**：A signal fallback needs an installed exit handler and must remain unblocked in the target worker context.
+- **后果**：The worker does not exit and pthread_join() blocks indefinitely.
+
+## 涉及软件
+
+Threaded C/C++ software that owns joinable worker threads and directly uses pthread_cancel()/pthread_setcanceltype(), when the target libc omits the cancellation API.
+
+## 相关模式
+
+- **相似模式**：[E022](E022.md)
+- **根因条目（应先修它们）**：[E085](E085.md)、[E127](E127.md)
+
+---
+*条目 E513 · 更新 2026-08-12 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E514.md

@@ -0,0 +1,40 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E514: libtoolize aux-dir heuristic picks .. / ../.. because of a stray install.sh in a parent dir (ltmain.sh lands in the wrong directory)
+
+> **严重度**: 🟡 medium | **分类**: build-system, autotools, libtoolize | **自动修复**: ✅ pre-create-install-sh
+
+---
+
+## 错误特征
+
+```
+libtoolize: putting auxiliary files in '\.\.'\|\.\./\.\.
+required file '\./ltmain\.sh' not found
+automake failed with exit status 1
+```
+
+## 根因
+
+libtoolize's aux-dir heuristic scans '.', '..', '../..' for install-sh/install.sh; on the OHOS build host $HOME/tmp/install.sh exists (from a previous package install), so libtoolize chooses '../..' (= $HOME/tmp) as the aux dir and copies ltmain.sh there. automake then fails with 'required file ./ltmain.sh not found'.
+
+## 验证命令
+
+```bash
+autoreconf -fi && ls ltmain.sh && test -x configure
+```
+
+## 解决方案
+
+**ensure-install-sh-in-source-root**：Ensure install-sh (or install.sh) exists in the source root before running autoreconf so libtoolize picks '.' as the aux dir; the conan recipe writes a placeholder install-sh in build() before autoreconf -fi.
+
+```bash
+test -f install-sh || printf '#!/bin/sh\n' > install-sh; autoreconf -fi
+```
+
+## 涉及软件
+
+autotools projects bootstrapped with autoreconf -fi whose source root has no install-sh yet; any build host where a parent directory contains install.sh
+
+---
+*条目 E514 · 更新 2026-08-14 · 知识库同步生成物*

package/node_modules/@ohos-agent/pc-adapter/skills/pc-error-atlas/knowledge/errors/E515.md

@@ -0,0 +1,39 @@
+<!-- 本文件由同步脚本自动生成，请勿手改。如需修正请更新知识源数据后重新运行 `npm run sync:kb`。 -->
+
+# E515: conan patch 默认 strip=0，refresh-patch a/b 前缀补丁需显式 strip:1
+
+> **严重度**: 🔴 blocking | **分类**: conan, packaging, patch | **自动修复**: ❌
+
+---
+
+## 错误特征
+
+```
+Failed to apply patch.*source/target file does not exist
+Patch file does not exist
+```
+
+## 根因
+
+refresh-patch 生成的补丁是 Git 风格 a/xxx b/xxx（需 -p1 剥离），但 conan 的 apply_conandata_patches() 默认 strip=0 不剥离前缀，patch_ng 找不到 a/xxx 文件报 source/target file does not exist（信息不指向 strip 问题）。conandata.yml 每个 patch 条目需显式 strip:1。
+
+## 验证命令
+
+```bash
+conan create 通过；conandata.yml patches 条目含 strip:1
+```
+
+## 解决方案
+
+**approach-identifier          # 见 DESIGN §5 impl 列表**：approach-identifier # 见 DESIGN §5 impl 列表
+
+```bash
+可选: 具体命令模板(${VAR}变量引用)
+```
+
+## 涉及软件
+
+所有使用 refresh-patch 生成补丁 + conan apply_conandata_patches 的配方
+
+---
+*条目 E515 · 更新 2026-08-28 · 知识库同步生成物*