确认是否真用LLVM libc++需查二进制：readelf -d看NEEDED字段，有libc++.so.1且无libstdc++.so.6为关键证据；同时检查头路径、符号ABI tag（如std::__1::string）、崩溃信息及libcxxabi.so.1依赖。
程序是否真用了 LLVM libc++，不能只看编译命令有没有 -stdlib=libc++，得从二进制里“抓现行”——因为链接器可能悄悄 fallback 到 libstdc++.so，尤其在头文件路径和库路径混杂时。
查 ELF 的 NEEDED 条目是最硬的证据
运行时加载器只认 NEEDED 字段声明的依赖，这个字段写死在 ELF 里，不受环境变量干扰。用 readelf -d 直接翻动态段：
- 如果输出里有
(NEEDED) Shared library: [libc++.so.1]，且没有[libstdc++.so.6]，基本可确认用了 libc++ - 如果同时出现
[libc++.so.1]和[libstdc++.so.6]，说明链接了两个标准库——这是严重错误，通常因 CMake 混用了find_package(Threads)或第三方库自带的target_link_libraries导致 - 若只有
[libstdc++.so.6]，哪怕编译命令写了-stdlib=libc++，也说明链接阶段被覆盖或未生效
验证头文件和符号是否匹配
编译时用了 libc++ 头，但链接错库，也会导致行为异常（比如 std::string 内存布局不一致）。检查两个关键点：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 运行
clang++ -x c++ -E -v /dev/null 2>&1 | grep "include"，确认输出中包含/usr/include/c++/v1（Linux）或XcodeDefault.xctoolchain/usr/include/c++/v1（macOS）——这是 libc++ 的头路径 - 用
nm -C your_program | grep "std::string::"，观察符号名是否含__1（libc++ 的 ABI tag），例如std::__1::string；而 libstdc++ 是std::string或带GLIBCXXtag
运行时崩溃或断言能暴露真实标准库
libc++ 的 debug 断言（如 vector::at() 越界）报错信息非常特征化：
立即学习“C++免费学习笔记（深入）”；
- 错误消息含
libc++abi: terminating with uncaught exception of type std::out_of_range: vector::_M_range_check—— 注意_M_range_check是 libc++ 特有命名，libstdc++ 报的是__throw_out_of_range或类似 - 用
gdb ./your_program启动后执行catch throw，停住时看栈帧：若顶层是std::__1::vector::at，而非std::vector::at，就坐实了 - 注意：部分发行版 libc++ debug 版本被 strip，
bt可能看不到源码行，但符号名里的__1仍可识别
最容易被忽略的是 libc++abi 的耦合关系
libc++ 本身不实现 ABI 符号（如 __cxa_allocate_exception），必须搭配 libc++abi。所以即使 readelf -d 看到 libc++.so.1，也得确认它没偷偷依赖 libstdc++.so 来补 ABI：
- 对
libc++.so.1本身再跑一次readelf -d | grep NEEDED，重点看是否含libcxxabi.so.1；若出现libstdc++.so.6，说明构建时 ABI 层被污染 - 用
nm -D libc++.so.1 | grep __cxa，若大量__cxa_*符号是U（undefined），说明它指望外部提供，此时libcxxabi.so.1必须存在且版本匹配 - 静态链接场景下，加
-static-libc++后readelf -d应不再出现任何 libc++ 相关NEEDED，但libc.so.6仍会保留——这是正常行为
