c++oding="utf-8" ?>
银河麒麟系统能编译运行C++程序，关键在于匹配架构与GCC版本、显式指定标准库路径、正确配置CMake编译器及统一ABI版本，避免因g++-8不支持C++20、libstdc++.so路径缺失或GLIBCXX版本不一致导致的编译失败、运行时错误和段错误。
银河麒麟系统上编译运行C++程序，核心不是“能不能”，而是“用对工具链+避开默认缺省陷阱”——尤其当你面对的是龙芯（loongarch64）、飞腾（aarch64）或兆芯（x86_64）等不同架构时，g++ 版本、标准库路径、CMake 默认生成器都可能悄无声息地出错。
确认系统架构和默认编译器版本
银河麒麟 V10 SP1 各版本（如 2403）虽统一基于 Linux 内核，但预装的 GCC 工具链版本差异极大：x86_64 平台常带 g++-11 或 g++-13，而 loongarch64 平台多数只预装 g++-8（不支持 C++20 的 std::span 等特性），aarch64 平台则可能混用社区版与麒麟定制版。不查清就写 g++ -std=c++20，大概率报 unrecognized command line option '-std=c++20'。
- 运行
uname -m确认架构（x86_64/aarch64/loongarch64） - 运行
g++ --version查看实际版本；若输出为g++ (GCC) 8.5.0，别硬上 C++20 - 运行
dpkg -l | grep g++（deb 系）或rpm -qa | grep gcc-c++（rpm 系）确认是否安装了多版本 - 必要时用
sudo apt install g++-11或sudo yum install gcc-c++-11显式安装高版本（注意源是否启用）
编译时必须显式指定标准库路径（尤其 loongarch64/aarch64）
银河麒麟部分国产 CPU 架构镜像中，libstdc++.so 不在默认 LD_LIBRARY_PATH 或链接器搜索路径里。你用 g++ main.cpp -o main 能编译成功，但运行时报 error while loading shared libraries: libstdc++.so.6: cannot open shared object file —— 这不是没装，是动态链接器根本没找到它。
- 先查库位置：
find /usr -name "libstdc++.so*" 2>/dev/null，常见路径如/usr/lib64/gcc/loongarch64-unknown-linux-gnu/8.5.0/libstdc++.so - 临时生效：编译时加
-Wl,-rpath,/usr/lib64/gcc/loongarch64-unknown-linux-gnu/8.5.0 - 永久生效（推荐）：把路径追加到
/etc/ld.so.conf.d/kylin-gcc.conf，再执行sudo ldconfig - 验证是否生效：
ldd ./main | grep stdc++应显示 “=> /path/to/libstdc++.so.6”
CMake 项目在麒麟上容易卡在 Ninja 找不到编译器
银河麒麟桌面版默认不设 CC/CXX 环境变量，CMake 自动探测时可能 fallback 到系统旧版 gcc，或者在交叉编译场景下完全找不到目标平台 g++。典型现象是 cmake .. 成功，但 ninja 报 g++: not found，即使 which g++ 明明有输出。
- 不要依赖自动探测：显式传参，例如
cmake -G Ninja -DCMAKE_CXX_COMPILER=/usr/bin/g++-11 .. - 检查
CMakeCache.txt中CMAKE_CXX_COMPILER:是否真被覆盖（有时缓存残留旧值） - 若用麒麟自研构建工具链（如 KMRE 相关 SDK），务必加载其提供的环境脚本，例如
source /opt/kylin-sdk/env.sh - 遇到 Ninja 报错但 Makefile 能跑通，说明是 Ninja backend 与麒麟 shell 环境变量隔离有关，可临时切回
-G "Unix Makefiles"
运行期常见段错误：不是代码问题，是 ABI 不匹配
在银河麒麟上从源码编译 Qt、OpenCV 等大型 C++ 库后，自己写的程序调用它们却频繁 Segmentation fault (core dumped)，十有八九是 ABI 层级不一致：比如你用 g++-11 编译主程序，但系统预装的 libopencv_core.so 是用 g++-8 编译的，std::string 内存布局或异常处理机制已变，一传参就崩。
- 用
readelf -d /usr/lib/x86_64-linux-gnu/libopencv_core.so | grep NEEDED查它依赖的libstdc++.so.6版本号 - 用
strings /usr/lib/x86_64-linux-gnu/libopencv_core.so | grep GLIBCXX查它编译时的 GCC ABI 标签（如GLIBCXX_3.4.22） - 对比你的可执行文件：
strings ./main | grep GLIBCXX，若版本低（如只有GLIBCXX_3.4.20），说明你编译器太老 - 最稳妥解法：所有组件（包括系统库）统一用同一 GCC 版本重新编译，或改用麒麟官方提供的二进制 SDK 包（含 ABI 兼容保证）
真正麻烦的从来不是“怎么写第一行 cout”，而是当 g++ 没报错、ldd 显示全绿、core dump 却在第 37 行随机触发时，你得知道该去翻 GLIBCXX 版本号，而不是重写逻辑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
