根本原因是gcc调用的底层工具（如as、ld）或系统c库在非utf-8 locale下无法正确处理宽字节中文路径，导致文件查找失败或子进程启动异常。
gcc在中文路径下报错：No such file or directory
根本原因不是gcc本身不支持中文，而是它调用的底层工具（比如as、ld）或系统C库对非UTF-8 locale下的宽字节路径处理异常。常见现象是编译时提示fatal error: xxx.h: No such file or directory，但文件明明存在；或者直接卡在预处理阶段，报错cc1: fatal error: cannot execute ‘cc1’: No such file or directory——这其实是路径解析失败导致子进程启动失败。
- 临时验证：把源码移到纯英文路径（如
/home/user/project）再编译，如果立刻成功，基本可锁定是路径问题 - 不要试图改locale硬扛：设置
LANG=C或LC_ALL=C可能让gcc启动，但头文件包含、宏展开等环节仍会出错，不可靠 - MinGW-w64在Windows上对中文路径更敏感，连
gcc -v都可能崩溃，必须规避
cmake + gcc遇到中文路径时CMAKE_C_COMPILER检测失败
CMake在初始化阶段会尝试运行gcc --version并捕获输出，一旦gcc因路径问题提前退出（哪怕只返回非零状态），CMake就认为编译器不可用，抛出CMAKE_C_COMPILER not set。这不是配置问题，是底层执行链断裂。
- 检查方式：手动执行
gcc --version，如果终端直接卡住或报错，说明gcc自身已无法在当前路径下工作 - 不要在CMakeLists.txt里硬编码
set(CMAKE_C_COMPILER "/path/to/gcc")：路径里含中文时，CMake内部仍会调用它，失败逻辑不变 - 唯一有效解法：确保整个构建树（源码目录、build目录、toolchain文件）全在ASCII路径下。例如
C:/dev/myproj可行，C:/用户/项目不行
交叉编译器arm-linux-gnueabihf-gcc也受中文路径影响
交叉工具链通常由多个二进制组成（arm-linux-gnueabihf-gcc、arm-linux-gnueabihf-as、arm-linux-gnueabihf-ld），它们共享同一套路径解析逻辑。只要其中任一环节（比如链接器读取脚本路径）遇到中文，整个编译就会中断，错误信息往往指向cannot find -lc这类误导性提示。
- 即使
PATH和LD_LIBRARY_PATH都正确，中文路径仍会导致动态链接器ld-linux.so.3加载失败 - 不要尝试用
chcp 65001（Windows UTF-8模式）修复：gcc二进制本身不读取该设置，无效 - 最稳妥做法：交叉编译器安装路径、项目路径、甚至临时
/tmp目录（某些工具会在此解压中间文件）全部使用英文无空格路径
为什么有些情况看似能编译成功？
部分Linux发行版（如Ubuntu 22.04+）在glibc 2.35后对UTF-8路径做了有限兼容，但仅限于简单文件名（如源文件.c），一旦涉及include路径、链接脚本、或绝对路径参数（-I/home/用户/include），仍大概率失败。这种“偶发成功”反而更危险——上线后在另一台机器上突然崩掉。
真正稳定的边界只有一个：所有参与构建的路径字符集严格限定为ASCII。这不是过度保守，而是GCC工具链几十年来未被彻底修复的底层约束。
