原始内容只留下了一张报错截图,这里把它整理成一个可回看的排查入口。
1. 关注的报错
原始记录对应的是这类链接错误:
linker file format not recognized
原笔记保留的截图如下:
2. 先把它当成什么问题看
整理后更适合把这类报错理解为:
链接器拿到的输入文件,不是当前工具链期望的目标格式。
常见方向通常不是“某一行 C++ 代码写错了”,而是下面几类输入有问题:
- 架构不匹配
例如把arm64-v8a的库喂给了armeabi-v7a目标,或反过来。 - 文件类型不对
例如把文本文件、压缩包、脚本,甚至错误下载的 HTML 文件当成.a/.so去链接。 - 产物损坏
下载不完整、拷贝中断、缓存污染,都可能导致格式异常。 - 主机库和目标库混用
例如把本机 Linux 库误当成 Android NDK 目标库参与链接。
3. 最小排查顺序
回看这条记录时,建议先按下面顺序确认:
1. 看报错里点名的是哪个文件
先从完整链接日志里找到具体是哪个 .o、.a 或 .so 触发了报错,而不是只记住“链接失败”。
2. 确认文件真实类型
优先确认它到底是不是目标文件 / 静态库 / 动态库,而不是只看扩展名。
3. 确认 ABI 是否一致
重点核对:
- 当前构建目标 ABI
- 依赖库实际 ABI
- 使用的 NDK 工具链前缀
4. 确认产物来源
如果这个文件来自第三方包、脚本下载或手工拷贝,优先怀疑:
- 下载到了错误内容
- 缓存里残留旧版本
- 误用了 host 侧产物
4. 这条笔记真正想提醒什么
这篇记录虽然短,但核心价值是提醒自己:
遇到 file format not recognized 时,先查输入产物和 ABI,不要先钻进源码细节。
FEATURED TAGS
Git
Cheat Sheet
Markdown
Tools
C++
Linker
Thread
Linux
TCP
Network
GDB
Debug
leetcode
链表
WSL
Ubuntu
Windows
Linux Kernel
GCC
Android
adb
Troubleshooting
Profiling
Sanitizer
glibc
MySQL
Database
Python
curl
Build
ELF
clang-format
CMake
Graphviz
Performance
vcpkg
Protobuf
排查
速查
内存
STL
调试
性能分析
性能
读书笔记
方法论
架构
网络
Timer
mbedTLS
TLS
安全
负载均衡
脚本
工具
LRU
二叉树
BST
中序遍历
回溯
二分查找
优先队列
排序
旋转数组
jenkins
部署