根本原因是clang++启用LTO后生成LLVM bitcode格式的.o文件，而GNU ld只支持ELF格式；解决方案是改用支持bitcode的lld链接器或关闭LTO。
直接换链接器，或者关掉 LTO —— 这不是编译器报错，是链接器 ld 拒绝处理它看不懂的文件格式。
为什么 clang++ 生成的 .o 文件被 ld 报 “file format not recognized”
clang++ 默认启用 LTO（Link Time Optimization）时，会把目标文件编译成 LLVM bitcode（不是 ELF），而 GNU ld 只认 ELF。你看到的 CMakeFiles/xxx.dir/src/main.cc.o 看似是普通目标文件，file CMakeFiles/xxx.dir/src/main.cc.o 一查就会显示 LLVM IR bitcode file。
这不是 clang 或 CMake 配置错误，而是工具链不匹配：bitcode → 必须用 lld，不能用 ld。
- 常见触发场景：
-flto显式开启、CMake 中设置set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)、CLion 默认启用 LTO 的 libc++ 项目 - 错误现象固定：
file not recognized: file format not recognized出现在链接阶段，且只报 .o 文件（不是 .so/.a） - 别白费力气 clean/rebuild/ccache 清理 —— bitcode 文件每次重编译还是 bitcode
用 lld 替代 ld：三步生效
LLVM 自家的链接器 lld 能原生处理 bitcode，且速度比 ld 快。关键是要让 CMake/C++ 工具链真正用上它。
Clang 22.1.3
下载
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
- 确认已安装：
lld --version（Ubuntu/Debian 上装llvm包即含lld；macOS 用brew install llvm） - CMake 命令行加参数：
-DCMAKE_LINKER=/usr/bin/lld（Linux）或-DCMAKE_LINKER=/opt/homebrew/opt/llvm/bin/lld（macOS Homebrew） - 或在
CMakeLists.txt里写：set(CMAKE_LINKER "/usr/bin/lld" CACHE FILEPATH "linker") - Clang 编译时也可显式指定：
clang++ -flto -fuse-ld=lld ...，但 CMake 层面统一控制更稳妥
关掉 LTO：快速验证是否根因
如果暂时不想引入 lld，关 LTO 是最直接的验证方式 —— 成功链接就坐实了 bitcode 问题。
- CMake 中删掉或注释掉：
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON) - 或手动禁用：
add_compile_options(-fno-lto)、set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fno-lto") - 注意：关 LTO 后，
-stdlib=libc++不再引发冲突，但会损失优化收益 - Qt Creator / CLion 用户：检查 Build Settings → CMake → Additional Generator Options 是否隐含带了
-flto
其他可能但少见的 “file format not recognized” 场景
bitcode + ld 是主因，但还有几个容易混淆的点：
-
libclang.so报错？大概率是跨平台解压：Windows 下下载的 LLVM 预编译包，直接拷到 Linux 解压使用 ——libclang.so实际是 Windows DLL，ld当然不认识 - 源文件没后缀（如叫
main而非main.cpp）？cc main会被误当链接脚本处理，报treating as linker script - 交叉编译时混用工具链：比如用
arm-linux-gnueabihf-gcc编译，却用宿主/usr/bin/ld链接 —— 目标格式（ARM ELF）和宿主链接器不兼容
真正麻烦的是 bitcode 和链接器不匹配 —— 它不报错在编译阶段，等你改完十处代码、clean 三次、重装 clang 才发现，链接器根本没换。
