LLVM libc++链接时出现std::__1未定义符号怎么办-C++-PHP中文网

c++oding="utf-8" ?>

链接libc++时报std::__1未定义符号，是因为项目链接ndk的libc++_shared.so（std::__ndk1）却使用了系统libc++.so的头文件（std::__1），导致abi不匹配；根本原因是stl头文件来源与链接库不一致，常见于手动指定-lc++、误用系统头路径或cmake中stl配置混乱。

llvm libc++链接时出现std::__1未定义符号怎么办

为什么链接 libc++ 时会报 std::__1 未定义符号

因为你的项目实际链接的是 Android NDK 提供的 libc++_shared.so（命名空间为 std::__ndk1），但代码或头文件却隐式依赖了系统 libc++.so 的符号（命名空间为 std::__1）。两者 ABI 不兼容，链接器找不到 std::__1::string 这类符号，就直接报 undefined reference。

这不是你少加了某个库，而是 STL 实现和头文件/链接目标不匹配——常见于：手动指定 -lc++、误用系统头文件路径、或 CMake 中混用了不同 STL 配置。

CMake 中必须统一 STL 类型和头文件来源

NDK 的 CMake 工具链要求 CMAKE_ANDROID_STL_TYPE 和实际使用的头文件、链接库严格一致。一旦不一致，std::__1 和 std::__ndk1 就会打架。

确保只通过 CMAKE_ANDROID_STL_TYPE 控制 STL，不要手动加 -lc++ 或 -lc++_shared
禁止在 include_directories() 或 CMAKE_CXX_FLAGS 中硬塞 NDK 的 sources/cxx-stl/llvm-libc++/include 路径——它对应旧版 std::__1，已弃用
正确做法是让 NDK 自动注入头文件路径：只要设置了 set(CMAKE_ANDROID_STL_TYPE c++_shared)，CMake 就会把对应 std::__ndk1 的头文件和库路径加进去
检查是否在 Android.mk 或 Application.mk 中残留了 APP_STL := c++_shared 和 CMake 双重控制——删掉旧 mk 文件，只留 CMake 配置

如何确认当前实际链接的是哪个 libc++

运行 adb shell cat /proc/<pid>/maps | grep c++</pid> 查看进程加载的动态库；或在构建后用 readelf -d libyourlib.so | grep NEEDED 看依赖项。如果看到 libc++_shared.so，但报错是 std::__1，说明头文件来自别处。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

更直接的方法是检查预处理输出：clang++ -E -x c++ yourfile.cpp | grep -A2 -B2 "string"，看 std::string 展开后是 std::__1::string 还是 std::__ndk1::string。如果是前者，说明头文件没走 NDK 的标准路径。

临时验证：在源文件开头加 #include <__config></__config>，然后 #pragma message("STL namespace: " STRINGIFY(_LIBCPP_NAMESPACE))（需定义 STRINGIFY 宏）
若输出 __1，说明你 include 的是旧头文件；若输出 __ndk1，才是对的

最容易被忽略的坑：第三方静态库自带 libc++ 头文件

某些预编译的 .a 库（比如老版本 FFmpeg、OpenSSL 的 Android 构建产物）内部硬编码了 std::__1 的头文件路径，或者自己打包了一份 libc++ 头文件。当你链接它时，编译器会优先使用它的头文件，导致声明用 std::__1，而链接却去找 std::__ndk1 的实现。

这种问题不会在编译时报错，只在链接阶段爆发，且难以追踪。