Documentation › python-ninja-audit

Python / Ninja / Meson 调用点审计 + Linux-PAM 1.7.2 Makefile 移植技术底稿

生成时间：2026-09-19。范围：原构建重建计划（已清理，历史版本可从 Git 查看） §2 末两段、§3、§9、§12 P0。 方法：只读检查（ls/grep/find/file/diff/AST 解析/读取既有构建产物）。未修改任何源码，未运行 build.py。

标注约定：

• [E] = 已实证（附路径与行号，或可复现的只读命令）。
• [S] = 推测（未验证，不作为决策依据）。

主要证据源（都是仓库内既存文件，可复跑校验）：

第一部分 任务 A：Linux-PAM 1.7.2 → 手写 Makefile 移植

A.0 结论与难度评级（先给答案）

可行，且比预期的简单。 总体难度评级 中等（3/5）；其中"生产安装子集"（49 个链接产物）难度 中低（2/5），风险集中在 配置探测的等价 与 安装语义等价（soname 链 / RPATH 剥离 / setuid 模式），而不是编译本身。

决定性事实（全部 [E]）：

1. 45 个模块共用一份模板。modules/*/meson.build 全部是符号链接指向 modules/module-meson.build（516 行），md5sum 45 份完全相同。[E] ls -la build/auth-upstream/src/Linux-PAM-1.7.2/modules/pam_unix/meson.build → ../module-meson.build。 → 模块部分可压成 一张声明表（模块名 → 额外源文件 / 额外宏 / 额外库 / 跳过条件），不需要 45 个 Makefile。
2. docs=disabled 已经把整条 XML/xslt/docbook 链砍掉。[E] linux-pam-build.json commands 中有 -Ddocs=disabled；meson.build:492-592 全部在 if enable_docs 内；root/usr/share/man/ 里没有任何 PAM man 页。 → 移植不需要 xsltproc/xmllint/fop/w3m/xmlcatalog，也不需要 custom-man.xsl。
3. flex/bison 只服务于一个不安装的可执行文件。[E] conf/pam_conv1/meson.build:1-25 生成 pam_conv_y.[ch]/pam_conv_l.c 并 executable('pam_conv1', ...) 没有 install:；meson-info/intro-installed.json 的 161 条里 没有 /sbin/pam_conv1。 → 生产子集完全不需要 bison/flex。
4. 构建期不需要以宿主方式运行任何目标端可执行文件。[E] musl.ini 有 needs_exe_wrapper = true；build.ninja 里所有 CUSTOM_COMMAND 只有 bison/flex/msgfmt/meson --internal *（见 A.4）。目标端 unix_chkpwd/faillock/pam_timestamp_check 只被链接、从不被执行。pam_cap 不在本项目里（没有 libcap 依赖）。
5. 唯一"必须保留"的生成步骤只有 3 类：config.h（34 个宏）、pam_namespace_helper/pam_namespace.service（2 个 @SCONFIGDIR@ 文本替换）、82 个 .mo（msgfmt，外部成熟工具，非 Python）。
6. 发现的等价陷阱：当前 meson 基线实际上没有应用上游的 22 个 -W 加固警告旗标，也没有 -U_FILE_OFFSET_BITS（详见 A.2.4）。这不是移植引入的，移植后若"照抄上游意图"会产出与基线不同的参数集，必须在验收口径里显式处理。

不推荐的替代路线：降级 PAM 版本 / 删认证 / 给 meson 开例外 —— 已被用户否决，本文不再评估。

A.1 meson.build 实际定义的编译单元、生成步骤与依赖 [E]

A.1.1 文件全集与角色

顶层 meson.build 663 行；子目录 74 个 meson.build。按角色分：

A.1.2 实际构建产物（来自上次真实 meson 构建，不是读代码猜的）

[E] meson-info/intro-targets.json：180 个 target = 84 custom（82 .mo + pam_conv_y.[ch] + pam_conv_l.c）+ 50 executable + 39 shared module + 3 shared library + 1 static library + 2 run + 1 alias。 [E] build.ninja：158 条 c_COMPILER 边、92 条 c_LINKER 边、42 条 SHSYM 边。

modules/pam_*/ 有 6 个在配置期被探测结果 subdir_done() 掉，所以 45 → 39：

[E] 被跳过的 6 个：pam_lastlog（option('pam_lastlog') 默认 disabled，meson_options.txt:100）、pam_rhosts（无 ruserok/ruserok_af，musl 不提供，module-meson.build:61-64）、pam_selinux/pam_sepermit（无 libselinux，:70-79）、pam_tty_audit（无 struct audit_tty_status，:99-101）、pam_userdb（无 db/gdbm/ndbm，:107-111）。

A.1.3 构建期生成的源文件（穷举）

注意 .pc.in 是死文件：[E] grep -rn "pc.in" /meson.build meson.build 零命中；root/lib/pkgconfig/pam.pc 缺 exec_prefix 行且键序与 libpam/pam.pc.in 不同 → 证实由 pkgconfig.generate 而非模板产出。移植时直接按 meson 实际输出写 3 个 10 行文件即可（内容见 A.5.5）。

没有任何 generator() 用法，也没有 header 生成脚本、.c 生成器。[E] grep -rn "generator(" --include=meson.build . 零命中。pam_appl.h 等 9 个安装头全部是静态文件（find -name '*.h.in' 零命中）。

A.1.4 依赖关系（真实链接图）

[E] 取自 build.ninja 的 LINK_ARGS：

libpam_internal.a          <- pam_debug.c pam_econf.c pam_line.c            (无外部依赖)
libpam.so.0.85.1           <- 33 objects + libpam_internal.a
                             --version-script=libpam/libpam.map  -Wl,-soname,libpam.so.0
libpamc.so.0.82.1          <- 3 objects  + libpam_internal.a                 map: libpamc.map
libpam_misc.so.0.82.1      <- 2 objects  + libpam_internal.a + libpam.so     map: libpam_misc.map
modules/*.so (shared_module) <- 自身 objects + libpam_internal.a + libpam.so + <可选 libcrypt.so>
                             --version-script=modules/<m>/module.map，name_prefix 空，**无 soname**
sbin/unix_chkpwd 等 exe     <- 同上 + -pie（project default_options b_pie=true）

模块 map 文件是 每个模块一份 module.map（源码里就有），移植时必须原样传给链接器 —— 它决定导出符号集，是 ABI 的一部分。

A.2 交叉编译选项与被 dependency() 发现的外部库 [E]

A.2.1 musl.ini（由 build_auth_upstream.py:103-113 生成）逐项语义

--gcc-toolchain=/nonexistent 是用来压制 clang 对宿主 GCC 的隐式发现的（[S] 推断，未查 clang 文档）。

A.2.2 命令行 -- 选项

build_auth_upstream.py:157-162 [E]：--prefix=/usr --libdir=/lib --sbindir=/sbin --sysconfdir=/etc --localstatedir=/var。 → 影响 _PAM_ISA（../../lib/security）、SECUREDIR、SYSCONFDIR、SCONFIGDIR、sbindir 注入到各 -D*_HELPER= 宏。

A.2.3 四个 -D 选项的确切语义

meson compile 传 -j12；meson install --destdir <root>；再次进入时加 --reconfigure --clearcache（:160-162）。

A.2.4 dependency() / find_library() 的实际解析结果

[E] 权威来源：meson-info/intro-dependencies.json —— 只有 3 个真正落地：

未解析（自动 disabled，不产生任何宏）：audit、libeconf、libselinux、libpwaccess、libcrypto(openssl 默认 disabled)、libsystemd/libelogind、libtirpc/libnsl(NIS)。 find_library('util')（pam_lastlog）、db/gdbm/ndbm（pam_userdb）也未命中。

→ 移植时的外部库集合就三个：libxcrypt（必需，且是唯一 pkg-config 探测）、musl 自带 libc（dl/intl 都由它满足）。 libmd/libbsd 不参与 PAM（它们只被 shadow/libbsd 链使用，见 build_auth_upstream.py:126-128 的 libbsd→libmd、shadow→libbsd 依赖闭包）。

libxcrypt 必须先于 linux-pam 安装到 staging：[E] build_auth_upstream.py:122-123（if "linux-pam" in selected: selected.add("libxcrypt")），order 元组把 libxcrypt 排在 linux-pam 之前。

A.2.5 全局编译/链接旗标的"真实值"（重要陷阱）

[E] 代码意图 vs build.ninja 实际：

根因 [E]：meson-logs/meson-log.txt:61-64

Command line: `clang ... -fuse-ld=lld --rtlib=compiler-rt ... -c ... -Werror=unused-command-line-argument -Wbad-function-cast` -> 1
clang: error: argument unused during compilation: '-fuse-ld=lld' [-Werror,-Wunused-command-line-argument]
clang: error: argument unused during compilation: '--rtlib=compiler-rt' [-Werror,-Wunused-command-line-argument]

meson 的"参数是否支持"探测用只编译不链接的方式跑，而 cross 文件把 -fuse-ld=lld/--rtlib=compiler-rt 混进了 c = [...] 主命令；这两个旗标在 -c 阶段未使用 → meson 自带的 -Werror=unused-command-line-argument 把探测判失败 → 22 个警告旗标被静默丢弃（grep -c "Compiler for C supports arguments" = 3318 次，全部 NO）。

这是一条独立于本次迁移的现存缺陷，应当在迁移台账里记账：基线产物不含上游加固警告集。移植方案必须显式声明自己走哪条路（见 A.6.3 判据 P3）。

A.3 patches/linux-pam/ 三个补丁 [E]

验证 [E]：diff -u src/.../meson.build adapted/linux-pam-404f.../meson.build 的唯一差异就是 crypt_rn 那一行；grep -n crypt_rn meson.build → 260:。

0001 与 0002 都改 passverify.c → 顺序敏感，现有脚本按文件名排序串行应用（build_auth_upstream.py:130 sorted(glob('*.patch'))），移植后保持同一顺序即可。

移植后的补丁策略建议（对应 §9"补丁在配置专属工作目录应用"）： 把 0002 拆成 0002a-*（仅 C + 新头，进 patches/linux-pam/）和"探测项 crypt_rn"（进我们自己的 config 生成器输入清单）。理由：给 meson.build 打补丁在 Make 路线上没有落点，保留会让补丁永远冲突。 注意 pam_userdb.c 那一段修改的是一个根本不构建的模块（无 db），拆补丁时可保留（无害）但应在台账中注明"该 hunk 在生产配置下不产生任何效果"。

旁证 [E]：adapted/linux-pam-404f.../modules/pam_unix/passverify.c.orig 与 .../pam_pwhistory/opasswd.c.orig 存在 → 说明当前 patch 调用留下了 .orig（build_auth_upstream.py:135 用 --batch --forward --fuzz=0，但 .orig 来自 patch 对新建文件的处理）。移植脚本应显式 --no-backup-if-mismatch 或用干净目录，避免 .orig 被 glob 成源文件。

A.4 交叉工具链 / sysroot 传入，与"宿主方式跑一次"需求

A.4.1 工具链传入方式

[E] PAM 这条路径不使用 leonos_musl_cc.py。build_auth_upstream.py:90-96 自己拼了一份 clang argv 并同时注入三处：环境变量 CC（给 autotools 包）、musl.ini [binaries].c 列表（给 meson）、build.json.compiler（记账）。leonos_musl_cc.py 只在 SDK 侧出现（A.4.3）。

同一份 argv 里有两个"绝对宿主耦合"点，移植时必须参数化：

• -isystem /usr/lib/clang/22/include ← clang -print-resource-dir 的产物（build_auth_upstream.py:87），版本号硬写在缓存里；
• --sysroot=<abs>/build/musl/sysroot、-idirafter <abs>/build/linux-6.12-headers/include。

Linux 头文件由 make ARCH=x86_64 headers_install 现场生成（build_auth_upstream.py:85）—— 这是纯 Make，可直接留在新体系里（§9 允许）。

musl sysroot 的一致性由 .leonos-musl.json 的 sources/target 双校验保证（:72-75），移植要保留同等检查。

A.4.2 目标端可执行文件"以宿主方式跑一次"清单 —— PAM：空

[E] 穷举 build.ninja 里所有 CUSTOM_COMMAND 的 COMMAND =（去重）只有： /usr/bin/bison、/usr/bin/flex、/usr/bin/msgfmt ×82、/usr/bin/meson 自身（dist/install --no-rebuild/--internal cleantrees/--internal gettext pot/--internal gettext update_po/--internal scanbuild/--internal uninstall/meson test）、以及 42 条 SHSYM = /usr/bin/meson --internal symbolextractor ...。

结论：没有任何目标端 ELF 在构建期被执行。needs_exe_wrapper=true + meson test 未被调用（生产链只跑 meson setup/compile/install）。所以 pam_cap（本项目无 libcap，不构建）、unix_chkpwd（只链接）都不需要 host 版。

endian / 尺寸探测：[E] meson.build 里唯一的类型探测是 cc.sizeof('long') >= 8（:116，因 A.2.4 的原因当前实际为"探测失败→跳过"）与 cc.sizeof('struct audit_tty_status')（:241，audit 不存在所以不执行）。endian 完全来自 cross 文件声明。没有 cc.run()、没有 alignmentof 探测。

A.4.3 需要顺带注意的"宿主跑一次"邻居（非 PAM，但在同一子图）

A.5 最小可行移植方案

A.5.0 规模结论

对象数核算 [E]：3 + 33 + 3 + 2（库）+ 55（39 模块：34×1 + faillock3 + namespace3 + pwhistory3 + timestamp3 + unix9）+ 14（6 个可执行：3+1+2+1+6+1）= 110；含非安装子集 = 158 = build.ninja 的 c_COMPILER 边数。✓ 交叉验证通过。

A.5.1 目录/变量骨架

mk/third-party/pam/
  Makefile          # 49 个产物 + install 目标；递归自顶层 make，继承 jobserver（§6.1）
  config.mk         # 路径推导（prefix/libdir/sbindir/sysconfdir/securedir/vendordir）
  probe.mk          # 探测清单 -> 驱动 gen-config-h
  modules.mk        # 模块声明表（45 行）
  gen-config-h.c    # tools/host 下的 C 工具：读 probe 结果 + 路径 -> 写 config.h（write-if-changed）
  subst.c           # 或者复用同一个 C 工具做 @SCONFIGDIR@ 替换

关键：把 meson 的 cdata 变成一个显式的、被版本控制的探测清单（哪些头/函数需要探测 + 期望值），而不是每次构建重新猜。理由见 A.6.1。

A.5.2 config.h 生成（唯一真正需要"重新实现"的部分）

[E] 目标产物就是现成的：build/auth-upstream/linux-pam-404f040518b42d15/libpam/include/config.h，34 个宏，逐条来源分类：

关键要求：探测必须产出一个可 diff、可版本控制的结果文件（例如 config.probed.txt），并做"内容不变 → 不更新 mtime"（§6.3），否则每次构建都会重编 110 个对象。

A.5.3 模块声明表（从 module-meson.build 逐条翻译，[E]）

不构建的 6 个（pam_lastlog/pam_rhosts/pam_selinux/pam_sepermit/pam_tty_audit/pam_userdb）必须在移植后继续不构建：root/lib/security/ 现在就没有它们，凭空多出来就是行为变更。

A.5.4 编译/链接旗标（照抄基线，不"顺手改进"）

[E] 逐字取自 build.ninja：

CC      = clang --target=x86_64-linux-musl --sysroot=... --gcc-toolchain=/nonexistent \
          -fuse-ld=lld --rtlib=compiler-rt --unwindlib=none -nostdinc \
          -isystem <musl>/include -isystem <clang-res>/include -idirafter <linux-headers>
CFLAGS  = -Wall -Wextra -O2 -g -mno-avx -mno-avx2 -D_FILE_OFFSET_BITS=64 -fPIC
          + -I<gen>（config.h 所在目录） -Ilibpam/include -Ilibpam_internal/include
          + 模块私有 -D（A.5.3 表）
          + libpam 专有：-DDEFAULT_MODULE_PATH="/lib/security/" -DLIBPAM_COMPILE
          + tests 专有： -DLIBPAM_COMPILE
          + pam_conv1 专有：-Wno-unused-function -Wno-sign-compare
LINK-SO  = -shared -fPIC -Wl,--as-needed -Wl,--no-undefined -Wl,--fatal-warnings \
           -Wl,--no-undefined-version -Wl,-O1 -Wl,-z,relro,-z,now \
           -Wl,--version-script=<map> [-Wl,-soname,libpam.so.0] --start-group ... --end-group
LINK-MOD = 同上但 **不加 soname**，且带 -Wl,--allow-shlib-undefined（meson 对 shared_module 的行为）
LINK-EXE = -pie + exe_link_args(-Wl,-z,relro,-z,now)

差异点必须保留 [E]：libpam.so 链接用 -Wl,--no-undefined，而模块用 -Wl,--allow-shlib-undefined（build.ninja:1474）。这不是笔误：模块允许引用 libpam 尚未导出的符号。

A.5.5 安装步骤（等价清单）

[E] meson-info/intro-installed.json 共 161 条 = 79 非 .mo + 82 .mo。分组：

/etc/environment                                        (pam_env/environment)
/etc/security/{access,faillock,group,limits,namespace,pam_env,pwhistory,time}.conf
/etc/security/namespace.init                            (mode 0755)
/etc/security/limits.d/                                 (空目录 install_emptydir)
/etc/security/namespace.d/                              (空目录)
/lib/libpam.so            -> libpam.so.0 -> libpam.so.0.85.1
/lib/libpamc.so           -> libpamc.so.0 -> libpamc.so.0.82.1
/lib/libpam_misc.so       -> libpam_misc.so.0 -> libpam_misc.so.0.82.1
/lib/security/pam_*.so                                  ×39
/lib/security/pam_filter/upperLOWER                     (可执行)
/lib/pkgconfig/{pam,pamc,pam_misc}.pc
/sbin/{faillock,mkhomedir_helper,pam_namespace_helper,pam_timestamp_check,pwhistory_helper,unix_chkpwd}
/usr/include/security/{_pam_compat,_pam_macros,_pam_types,pam_appl,pam_client,pam_ext,pam_filter,pam_misc,pam_modules,pam_modutil}.h   ×10
/usr/lib/systemd/system/pam_namespace.service
/usr/share/locale/<82 lang>/LC_MESSAGES/Linux-PAM.mo

另有 我们自己的 lib/security/pam_leonos_password.so（build_auth_upstream.py:229-247，独立 clang 命令，与 meson 无关，可原样搬）。

/etc/pam.d/* 不来自 Linux-PAM：meson 全树无 pam.d 安装语句（grep 确认），root/etc/pam.d/{chfn,chpasswd,chsh,login,newusers,passwd} 由 shadow 的 make install 提供。移植时不要把它算进 PAM 的验收清单。

特权元数据：/sbin/unix_chkpwd = uid 0, gid 0, mode 4755（[E] build_auth_upstream.py:214-218 与 linux-pam-build.json:image_permissions）。staging 里是 04755（[E] file sbin/unix_chkpwd → setuid ELF）。真正的 owner/mode 强制发生在镜像打包阶段，移植要保留这条双层契约。

A.5.6 非安装子集怎么处置

建议：默认不构建，作为显式 make pam-tests 目标（build_by_default 语义）。理由：pam_conv1 需要 bison+flex，tests/ 的 42 个可执行文件需要 tst-dlopen + aux/chdir_meson_build_subdir.sh 才能跑，且它们从不参与 rootfs。基线构建它们只是 meson "所有 target 默认全建"的副作用。

⚠ 这是与基线的一处有意的产物差异（基线多产出 48 个不安装的 ELF）。必须在台账里写明，不能被"PAM 装好了"这句话掩盖。

A.6 最难 / 最容易出错的部分

A.6.1 【最难】config.h 探测的等价性

• 用 -c 只编译 → 全部误判为"存在"→ pam_unix 链期才炸，或者更糟：静默生成错误 #undef 组合；
• 用宿主编译器探测 → glibc 结果 ≠ musl 结果（例如 HAVE_GETUTENT_R、HAVE_INNETGR 在 glibc 下为真，会把 pam_rhosts 错误地纳入构建，产出一个基线里不存在的模块）。

18 个函数探测里，至少 12 个在 musl 上是"链接才能确定"的（getgrgid_r、getspnam_r、lckpwdf、crypt_rn 等）。手写时常见的两个错： 并且 A.2.4 已经证明这套探测在现网 meson 路线上就已经错过一次。 建议把探测结果作为签入仓库的固定清单（配合 §9 的"依赖只读消费"），每次构建只做校验而不是重探，探测变化需要显式 make pam-reprobe。这也顺带满足 §7"相同输入不更新时间"。

A.6.2 【高频坑】对象文件命名冲突

• faillock.c + faillock_config.c → pam_faillock.so 与 sbin/faillock；
• opasswd.c → pam_pwhistory.so（无 -D）与 pwhistory_helper（-DHELPER_COMPILE="pwhistory_helper"）；
• bigcrypt.c → pam_unix.so、unix_chkpwd、bigcrypt 三份；
• md5_good.c/md5_broken.c/passverify.c/audit.c → 模块与 helper 两份；
• hmacsha1.c/sha1.c → pam_timestamp.so 与 hmacfile。

同一 .c 在多个产物里各编一份，且编译宏不同： 必须按产物分对象目录（§6.1 已要求）。混用会导致 helper 里带进模块的宏或反之。

A.6.3 【静默差异】meson 的 install 期 RPATH 剥离

[E] build.ninja:1474 链接时带 -Wl,-rpath,$ORIGIN/../../libpam:<abs>/build/auth-upstream/root/lib，但 llvm-readelf -d root/lib/security/pam_unix.so 没有 RPATH/RUNPATH，root/sbin/unix_chkpwd 也没有。 → meson 在 meson install 阶段改写掉了。手写 Make 若"链接即安装"会把开发者绝对工作区路径写进所有 39 个模块和 6 个 helper，同时违反 §9 与 §10（SDK 不得嵌入绝对工作区路径）的可移植精神，还会毁掉可复现性。 正确做法：链接期用 -Wl,-rpath-link=<staging>/lib（只解析、不写入）而非 -rpath。验收判据 P5。

A.6.4 【ABI】版本脚本与 -Wl,--no-undefined-version

42 个 map 文件（libpam.map、libpamc.map、libpam_misc.map、45×module.map）。-Wl,--no-undefined-version + --fatal-warnings 意味着版本脚本引用了未定义符号时链接失败——这是上游的 ABI 守卫，必须保留。若移植时因为某个符号在 musl 下未定义就顺手删掉 --no-undefined-version，等于放开 ABI。

A.6.5 【符号链接与打包】三件套 version/soname/link

shared_library(version:'0.85.1') → 实体 libpam.so.0.85.1 + SONAME=libpam.so.0 [E] readelf -d + 两条链。rootfs/APK 清单必须把符号链接作为独立条目（type=symlink）表达，而不是复制文件。

A.6.6 【范围蔓延】82 个 .mo

i18n=auto + 宿主有 msgfmt → 82 个安装项。它们有运行时意义（musl 自带 gettext 会加载，见 A.2.4 表）。移植要么保留 msgfmt（外部 C 程序，§5 允许），要么显式改变产品决定并记账。不能因为"只是翻译文件"就悄悄丢掉——那会让 79 条安装项变成 161-82=79 的伪等价通过。

A.6.7 【构建目录复用】--reconfigure --clearcache

build_auth_upstream.py:160-162 在已存在 build.ninja 时加 --reconfigure --clearcache，即每次强制重探。移植后如果沿用"探测一次即固化"，需要保证补丁摘要变化会让缓存签名失效（现脚本已经用 linux-pam-<patch_digest> 目录名做这件事，[E] :131-133）。要保留等价的失效键：上游摘要 ⊕ 补丁摘要 ⊕ profile 摘要 ⊕ 工具链身份。

A.7 可测试的等价验收判据（不以"能编译"为准）

参照物 = 仓库现存的 build/auth-upstream/root/（meson 基线）。所有判据都可用只读命令复核。

P1–P9 是硬判据；P10 是带说明的软判据；P11 是最终功能验收；P12 是本任务的存在性理由。

A.8 第三条路评估（实证，不臆测）

第二部分 任务 B：全生产链 Python / Ninja / Meson / CMake / Tcl 调用点审计

B.0 口径（三种"Python 调用点"，分开计数）

方法：AST 解析 build.py，枚举全部 157 个 Target(...) 字面量并按 command[0] 分类（脚本在 /tmp，只读）。所以生产链 = 157 − 51（test） = 106 个 target，其中 49 个直接跑 Python 子进程，23 个跑 Python 逻辑，22 个跑外部非 Python 程序，12 个是聚合/无命令。

换句话说："生产链 Python 调用点总数 = 72（49 子进程 + 23 进程内逻辑）"，最集中的几处见 B.7。

B.1 引擎自身（永远算 Python，直到入口切换）

B.2 T1：生产链 49 个 Python 子进程调用点（逐条）

分类列 = 归属阶段；替代难度 = 低（外部成熟工具或纯 argv 拼装的短 Shell）/ 中（有算法或格式，需 C 工具）/ 高（复杂格式/加密/需从零验证等价性）。

build.py:950/956/3645/3656/4330/4333 是 config-sync（tools/generate_component_kconfig.py + tools/kconfig_sync.py）的 3 处不同调用点（target action、run config-sync、defconfig），按 T2 计，见 B.6。

B.3 T3：Meson / Ninja / CMake 调用点 —— 只有 1 个组件

Ninja：只作为 M2 的内部执行器存在，仓库内无任何显式 ninja 调用（[E] grep -n '"ninja"' build.py tools/*.py 零命中，唯一 meson 字符串命中是 build.py:4681 的 --theme 选项名，与构建无关）。

CMake：零生产调用点 [E] grep -rn '"cmake"\|CMakeLists' build.py tools/*.py（非 test）零命中。third_party/{litehtml,mbedtls,mimalloc,libpng,zlib} 里有 CMakeLists.txt，但：

• mbedtls：只用 -Ithird_party/mbedtls/include + 显式源文件列表（[E] build.py:1145,1414）；
• zlib/libpng：ar rcs 自己归档（[E] build.py:1425,1434），libpng 的 pnglibconf.h 由 build.py 内联文本替换生成（[E] build.py:978-996，见 B.6）；
• mimalloc：只编 src/static.c 一个单元（[E] tools/build_musl.py:84-92）；
• litehtml：只被当作数据源读 src/encodings.cpp 抠 GBK 表（[E] build.py:1405,1408），完全不编译。

B.4 隐藏的二阶解释器调用（不在 build.py 视图里，最容易漏）

B.5 生成出来的包装器脚本的解释器（§2 显式点名项）

→ B.5 的唯一硬违规项就是 leonos-musl-cc。它约 40 行、纯 argv 拼装 + 一次 -print-resource-dir，改写成 C 或 POSIX Shell 的难度：低。这是"低成本、高价值"的第一优先项。

B.6 资源生成器与配置生成器的现状（全部无第三方 Python 库依赖）

[E] 逐个 grep "^import" 结果：generate_boot_logo.py(struct,zlib)、gen_loader_integrity.py(hashlib)、generate_gbk_table.py(re)、prepare_ui_font.py(struct,shutil)、make_app_icons.py/make_window_button_icons.py/make_minesweeper_assets.py/make_oschinpt_index.py(struct)、make_grub_font.py(仅 argparse/pathlib)、build_info.py(datetime)、apk_ownership.py/apk_distribution.py(json,hashlib,fcntl,tarfile,subprocess)。

好消息：没有一个用 PIL/第三方库（CI 装的 python3-pil 只服务 tools/test_*_qemu.py 的截图断言，[E] grep -l "from PIL" 的 6 个文件全是 test）。因此全部资源生成器都是"算法直译 C"，不存在必须引入图像库的风险。

进程内 Python 逻辑（T2，23 项，需等价重写）中最要紧的：

B.7 最集中的几处（按"去掉后清零收益"排序）

1. apk-root + esp:apk-ownership（build.py:3282 / :3258） —— 2 个调用点但承载整个包管理系统（签名/归属/索引/busybox --list 宿主执行/unshare 探测/fcntl 锁）。难度最高，且 §3 明令"不重写 APK 签名算法"，等价验证代价最大。
2. 三类镜像链：image-vmdk/image-iso/installer-/-live-root/musl-desktop-vim/musl-checkpoint（build.py:3366,3378,3385,3398,3443,3501,3507,3523,3530 = 9 个调用点） —— 全部经由 make_image.py / make_ext2_root.py（含 H3 的 fakeroot 自我重执）。GPT/FAT/ext2 布局逻辑在 Python 里，风险最高、回归面最大（§12 P3 的三条镜像验收全在这）。
3. auth-upstream（build.py:793 → build_auth_upstream.py:157-164） —— 唯一的 meson/ninja 源，且被 storage-upstream、esp:auth、SDK、rootfs 共同依赖（[E] build.py:816-820 storage 需要 auth 的 libuuid.a/libblkid.a；build.py:2390-2396 SDK 需要 --pam-root；build.py:2790 esp:auth）。修好 PAM 一处即让整条第三方链零 meson/ninja。
4. 第三方端口构建器族：build.py:1589,1644,1685,1765,1806,1865,1906,1944,1989,2028 = 10 个调用点 —— 同一个模式（Python 里拼 argv + 逐文件 clang + musl_link）。数量最多但最规整，一次性抽象成 mk/third-party/*.mk 模板即可批量清零。其中 busybox 与 ncurses/vim 本来就是 Make 体系，可直接递归 $(MAKE)。
5. 资源生成器族：build.py:1065,1200,1344,1401,2304,2329,2339,2343,2348,2516,3143 = 11 个调用点 —— 全部 stdlib-only 算法，机械翻译为 tools/host/{assets,version,manifest} C 工具（§5 已经按这个边界规划好了）。
6. SDK 包装器 leonos-musl-cc（B.5） —— 单个文件、约 40 行、低难度、却是 §2 的显式违规项。建议最先做。
7. 配置链 sync_config（build.py:964/3645/3656/4330/4333 = 5 个 Python 调用点） —— 4 处不同入口调用同两个脚本，替换点集中，是 §7 的 C Kconfig 前端落地位。

B.8 test-legacy 排除清单（既有 Python 回归测试）

[E] kind="test" 或以 test- 命名的 target 共 51 个，其中 37 个 的 command[0] 是 PYTHON（build.py:784,846,1857,3521,3681-3786,3801-3832）。它们启动的脚本：

tools/test_musl_abi.py、test_terminal_packages.py、test_fastfetch_package.py、test_live_iso.py、test_oobe.py、test_sudo_policy.py、test_builtin_tool_removal.py、test_installer_setup.py、test_installer_input.py、test_svga.py、test_license_server.py、check_unix_paths.py、test_linux_abi_contract.py、test_linux_memory.py、test_linux_process_vm.py、test_linux_sysv_msg.py、test_linux_sysv_sem.py、test_linux_pty.py、test_power.py、test_init_power.py、test_linux_permissions.py、test_storage_metadata.py、test_storage_rename.py、test_storage_mkdir_mount.py、test_ext2_cache.py、test_ext2_performance.py、test_ext2_write_batch.py、test_storage_write_batch.py、test_installer_copy.py、test_musl_distribution.py、test_uapi.py、check_abi_migration.py、test_component_config.py、test_kconfig_frontends.py、test_openrc_shutdown.py。

build.py:3736 的 test-los2w 用 PYTHON -c ...（内联代码）[E]。 build.py:4043-4107 的 12 个 test-qmp-* 是 action=Lambda / ACTION:qmp_test_suite（T2，进程内 Python + QEMU QMP）。

仓库内 tools/test_.py + tools/check_.py 共 132 个文件，绝大多数没有注册进 build.py 图（只在 CI 或手工调用）。它们的依赖：PIL（6 个 QEMU 截图类 [E]）、debugfs/qemu-img/openssl/unshare（外部工具）、socket/threading（标准库）。

归类建议：

• kind="test" 的 37 个 → test-legacy target，按 §2"列出依赖、不参与核心构建验收"。
• 其余 95 个未注册的 tools/test_*.py → 先出清单，逐个标"已注册/未注册/死代码"，不在本次删除（§3"不把全部 Python 文件视为旧构建残留"）。
• tools/prepare_gcc_probe.py、tools/package_musl_gcc.py、tools/package_python.py（往客户机里装 Python 应用，§2 明确不要求删）→ 非构建调度脚本，单独归类。

注意（红线）：test-musl-abi（build.py:784）与 test-terminal-packages（:846）在 depends_on 图上不在镜像/SDK 的生产闭包里（它们是 kind="test" 叶子）→ 可以安全归入 test-legacy。但 musl-probe:*（:1529）是 kind="link"、是 musl-probes 聚合的成员，build.py:1550；若 release 依赖 musl-probes，它就不是 test-legacy。[S] 需人工确认 all/release 的 depends_on 是否包含 musl-probes。

B.9 Rust 组件与 doctor 缺口

→ 计划 §2"Rust 组件的既有编译器依赖需在 doctor 和依赖表中列出"：rustc 已登记，但新增依赖表必须补 tclsh、msgfmt、pkg-config、patch、xz，并把 x86_64-unknown-none 是否需安装 rust-std 目标写清 [S]（当前用 -target x86_64-unknown-none，需 std-less 目标支持，未验证本机如何满足）。

B.10 CI 中非生产构建的部分

B.11 汇总

替代难度分布（T1+T2 的 72 项）：低 ≈ 13、中 ≈ 37、高 ≈ 22（高项集中在 APK 2 项 + 镜像 9 项 + 若干 stage/rootfs 逻辑 + PAM）。