链接libc++时报std::__1未定义符号，是因为项目链接NDK的libc++_shared.so（std::__ndk1）却使用了系统libc++.so的头文件（std::__1），导致ABI不匹配；根本原因是STL头文件来源与链接库不一致，常见于手动指定-lc++、误用系统头路径或CMake中STL配置混乱。
为什么链接 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++免费学习笔记（深入）”；
组合式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>，然后#pragma message("STL namespace: " STRINGIFY(_LIBCPP_NAMESPACE))（需定义STRINGIFY宏） - 若输出
__1，说明你 include 的是旧头文件；若输出__ndk1，才是对的
最容易被忽略的坑：第三方静态库自带 libc++ 头文件
某些预编译的 .a 库（比如老版本 FFmpeg、OpenSSL 的 Android 构建产物）内部硬编码了 std::__1 的头文件路径，或者自己打包了一份 libc++ 头文件。当你链接它时，编译器会优先使用它的头文件，导致声明用 std::__1，而链接却去找 std::__ndk1 的实现。
这种问题不会在编译时报错，只在链接阶段爆发，且难以追踪。
- 检查静态库是否含头文件：
ar -t libfoo.a | grep __，看有没有__config、string等 libc++ 内部头文件 - 用
nm -C libfoo.a | grep "__1::"确认它是否引用了std::__1符号 - 解决方式只有两个：换用重新用 NDK 正确编译的版本；或把该库改成动态链接（
.so），让它运行时加载同一份libc++_shared.so
这类冲突往往藏得深，不查符号表根本意识不到是第三方库在“偷偷换 namespace”。
