从日志中确认调用了 AR 生成 plat_1105.o，说明 用户分支的构建流程被修改，导致未按标准内核模块构建方式（LD -r）执行。以下是详细分析和解决方案：
1. 问题定位
(1) 日志分析
- 正常流程（开发分支）：
CC 1.c → 1.o
CC 2.c → 2.o
CC 3.c → 3.o
LD -r 1.o 2.o 3.o → plat_1105.o # 部分链接合并 - 异常流程（用户分支）：
CC 1.c → 1.o
CC 2.c → 2.o
CC 3.c → 3.o
AR rcs plat_1105.o 1.o 2.o 3.o # 静态库归档AR生成的plat_1105.o实际是静态库（.a格式），无法作为内核模块的输入。
(2) 根本原因
- Makefile 被覆盖：用户分支的
Makefile或构建脚本中可能包含类似以下规则：plat_1105.o: 1.o 2.o 3.o
$(AR) rcs $@ $^ # 错误！用 AR 替代了 LD - 构建系统差异：用户分支可能引入了定制化的构建逻辑（如非标准内核补丁）。
2. 解决方案
(1) 恢复标准内核构建流程
删除所有覆盖 LD -r 的自定义规则，确保 plat_1105.o 通过部分链接生成：
# 正确写法（依赖内核隐式规则）
obj-m += plat_1105.o
plat_1105-objs := 1.o 2.o 3.o # 自动触发 LD -r
(2) 检查并修复 Makefile
- 搜索所有调用
AR的位置：grep -r "AR" platform/ # 检查 Makefile 中是否有手动 AR 调用 - 删除或注释错误规则：
# 错误示例（需删除或修改）
# plat_1105.o: $(plat_1105-objs)
# $(AR) rcs $@ $^
(3) 验证构建命令
重新编译并检查日志：
make clean && make V=1 modules
- 预期输出：应看到
LD -r命令，而非AR。
(4) 检查文件类型
确认生成的 plat_1105.o 是部分链接的 ELF 文件：
file plat_1105.o
- 正常输出：
plat_1105.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), not stripped - 异常输出（若仍用
AR）：plat_1105.o: current ar archive
3. 深入排查
若问题仍未解决，可能是以下原因：
(1) 内核顶层构建脚本被修改
检查内核源码中的链接脚本：
grep -r "ld -r" scripts/ # 确认标准部分链接规则是否存在
grep -r "ar " scripts/ # 检查是否有 AR 的异常调用
(2) 工具链污染
确认使用的工具链与开发分支一致：
which aarch64-none-linux-gnu-ld # 检查 LD 路径
which aarch64-none-linux-gnu-ar # 检查 AR 路径
(3) 分支差异
对比用户分支与开发分支的构建系统文件：
git diff develop -- Makefile scripts/
4. 关键区别总结
| 特性 | LD -r 生成的 .o |
AR 生成的 .a |
|---|---|---|
| 文件类型 | 可重定位 ELF（部分链接） | 静态库（.o 的归档） |
| 用途 | 可继续链接为内核模块（.ko） |
仅供静态链接，无法直接加载为模块 |
| 符号处理 | 保留所有符号（包括局部符号） | 仅归档，不合并符号 |
| 文件大小 | 较大（含元数据和未优化符号） | 较小（仅原始 .o 的集合） |
5. 修复后验证
- 文件大小：用户分支的
plat_1105.o应接近开发分支大小（略小因优化差异）。 - 模块加载：确保
plat_1105.ko能正常加载到内核：insmod plat_1105.ko
总结
- 问题根源：用户分支错误地用
AR替代了LD -r，导致生成静态库而非部分链接文件。 - 修复方法：删除所有覆盖
LD -r的自定义规则，恢复内核标准构建流程。 - 调试技巧：通过
make V=1和file命令验证构建行为。
通过统一构建方式，可彻底解决分支间的差异问题！ 🛠️