libc++本身不实现栈展开逻辑，需依赖libunwind等ABI运行时库提供_Unwind_*符号以支持异常和RTTI；启用异常或RTTI时链接阶段必须提供可用实现，否则报undefined reference错误。
libc++ 默认不强制依赖 libunwind，但启用异常或 RTTI 时，链接阶段必须提供可用的 _Unwind_* 符号实现——否则会链接失败，报类似 undefined reference to '_Unwind_RaiseException' 的错误。
为什么 libc++ 需要 libunwind
libc++ 本身不实现栈展开逻辑，它把异常抛出（__cxa_throw）、类型信息（type_info）和栈回溯等底层工作交给 ABI 运行时库。libunwind 就是其中一种符合 Itanium C++ ABI 规范的展开器实现。如果你用 clang++ 编译并启用了异常（默认开启），而链接时找不到 libunwind 或等效实现（如 libgcc_s），就会在最终链接阶段失败。
- Ubuntu/Debian 上默认用
libgcc_s.so.1提供 unwind 符号，所以不显式链接libunwind也能过 - macOS 使用系统自带的
libunwind.dylib（Apple fork），通常透明 - 自建 toolchain（如用
libc+++libc++abi+libunwind全链路）时，必须手动指定libunwind路径和链接顺序
CMake 配置 libc++ 时如何指定 libunwind
构建 libc++ 项目（非仅使用预编译版）时，关键不是“配置 libc++ 依赖 libunwind”，而是确保 libc++abi 能找到并链接它——因为 libc++abi 才是直接调用 _Unwind_* 的那一层。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用 CMake 构建
libc++abi时，设置-DLIBUNWIND_LIBRARY=/path/to/libunwind.a和-DLIBUNWIND_INCLUDE_DIRS=/path/to/libunwind/include - 同时确保
libc++abi的 CMake 配置中LIBCXXABI_USE_LLVM_UNWIND为ON（启用 LLVM 自研 libunwind），或LIBCXXABI_USE_LIBGCC为OFF（禁用 GCC 的 unwind 实现） - 如果用系统级 libunwind（如 Ubuntu 的
libunwind-dev），则只需保证 pkg-config 可查：pkg-config --exists libunwind成功，CMake 通常能自动探测 - 注意链接顺序：最终链接可执行文件时，
-lc++ -lc++abi -lunwind必须按此顺序，否则符号解析失败
常见链接错误与绕过方式
最典型的错误是：undefined reference to '_Unwind_GetIPInfo'、'_Unwind_Backtrace' 等。这不是 libc++ 代码问题，而是链接时 unwind 库缺失或版本不匹配。
立即学习“C++免费学习笔记（深入）”；
- 快速验证：运行
nm -D /usr/lib/x86_64-linux-gnu/libunwind.so | grep _Unwind_GetIPInfo，确认符号存在 - Clang 用户常误以为加了
-stdlib=libc++就万事大吉，其实还必须配好libc++abi和底层 unwind；单独只编译 libc++ 是不够的 - 交叉编译（如 Android、嵌入式）时，
libunwind_llvm是更稳妥的选择，避免和系统libgcc_s混用导致 ABI 冲突 - 若只是想跳过异常支持（例如嵌入式无异常场景），可定义
-D_LIBCPP_NO_EXCEPTIONS并禁用 RTTI，彻底避开 unwind 依赖
真正容易被忽略的是：libunwind 的 ABI 兼容性极弱——不同版本之间 unw_cursor_t 大小、unw_context_t 布局可能变化，静态链接时尤其要注意来源一致。不要混用系统包安装的 libunwind 和自己从 llvm-project 编译的 libunwind_llvm。
