c++oding="utf-8" ?>
libc++与libstdc++互不兼容，因二者在std::string等模板实例的内存布局、符号修饰、异常处理及rtti结构上完全不一致，混用会导致运行时崩溃或未定义行为。
libc++ 和 libstdc++ 是互不兼容的 ABI 实现
libc++ 和 libstdc++ 都实现了 C++ 标准库接口，但它们的底层 ABI（应用二进制接口）完全不同。这意味着：同一类模板实例（比如 std::string 或 std::vector<int></int>）在两个库中内存布局、符号命名（mangling）、异常处理机制、RTTI 表结构都不可互换。你不能把用 libstdc++ 编译的目标文件（.o）和用 libc++ 链接的可执行文件混在一起——链接器可能通过，但运行时大概率崩溃或行为未定义。
符号冲突与链接器不会自动“翻译”ABI
当你显式写 -lstdc++ 时，链接器只负责按名字找符号并填地址，它不管这些符号属于哪个 ABI。如果项目一部分用 clang++ -stdlib=libc++ 编译，另一部分（比如某个预编译的第三方 .a）是用 g++ 编译并依赖 libstdc++ 的，那么：
- 链接阶段可能成功（尤其当没用到重叠类型时），但
- 一旦调用跨库的
std::string构造/析构、std::locale、或任何涉及虚表/异常栈展开的逻辑，就会出错 -
ldd看不到冲突，nm或c++filt可能显示看似一致的符号，但实际 ABI 不匹配
NDK 场景下 libc++_shared.so 找不到 libstdc++ 符号是设计使然
Android NDK 自 r18 起强制使用 libc++，并移除了 libstdc++ 支持。此时若你在 CMakeLists.txt 里写：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
target_link_libraries(mylib stdc++)
构建系统会尝试找 libstdc++.so，但它根本不存在于 NDK 的 sysroot 中——这不是路径问题，而是 ABI 策略裁剪。NDK 的 libc++_shared.so 里没有 _ZNSs4_Rep20_S_empty_rep_storageE 这类 libstdc++ 的符号，反之亦然。
- 不要试图用
LD_PRELOAD强行加载两个 C++ 库 - 不要在同一个进程里混用
std::string（来自 libc++）和std::string（来自 libstdc++）的指针或对象 - 如果必须集成旧的
libstdc++二进制，唯一安全方式是进程隔离（如 fork + exec）或 IPC
Clang 默认行为加剧了隐性混用风险
Linux 上 Clang 默认仍链接 libstdc++（除非加 -stdlib=libc++），而 macOS 上默认是 libc++。这就导致：
- 同一份
CMakeLists.txt在不同平台可能悄无声息地链接不同标准库 - 跨平台 CI 构建失败时，错误常表现为 undefined symbol，而非直接报“找不到库”
- 用
clang++ main.cpp -o a.out编译，再用nm a.out | grep string查看符号前缀，就能确认实际链接的是哪个实现
真正棘手的不是“链接不上”，而是“链上了却运行错”——这种 ABI 不兼容没法靠路径或版本号解决，只能统一工具链和标准库选择。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
