GCC报“Permission denied”通常因cc1等组件无执行权限、输出目录不可写或路径含空格导致，需依gcc -v定位具体失败环节再针对性修复。
直接看错误类型再动手，别一上来就 sudo。GCC 报 “Permission denied” 通常不是编译器本身没权限，而是它在找东西、跑东西或写东西时被系统拦住了——具体在哪一步卡住，决定了你该查什么。
检查 cc1 或其他内部组件是否可执行
常见于 GCC 配置异常或安装损坏：报错含 execvp: 'cc1': Permission denied 或 No such file or directory，说明 GCC 找不到或无法运行它的后端组件（如 cc1、as、ld）。
- 先定位
cc1路径：gcc -v hello.c 2>&1 | grep "using built-in specs"，或手动查：find /usr -name cc1 2>/dev/null - 确认该文件存在且有执行权限：
ls -l /path/to/cc1—— 若权限是----------或缺x，就出问题了 - 修复权限（仅限你拥有该目录）：
chmod a+x /path/to/cc1；如果是系统路径（如/usr/lib64/gcc/...），优先重装工具链，而非暴力chmod 777 - 若提示
No such file or directory但文件明明存在，可能是动态链接库缺失（如libz.so.1），用ldd /path/to/cc1检查
确认输出目录是否有写权限
最常被忽略的环节：GCC 编译成功后要往目标路径写 .o 或可执行文件，如果 -o /usr/local/bin/app 或 build/ 目录归属 root 或权限为 dr-xr-xr-x，就会在最后一步报 “Permission denied”。
- 运行
ls -ld build/或ls -ld /usr/local/bin，重点看第三段（other 权限）和所有者 - 不要直接
sudo make；改用用户可写的路径，例如mkdir -p ~/build && cd ~/build && gcc -o app ../src/main.c - 若必须写系统路径，确保你属于
sudo组且有对应权限，或用sudo install -m 755 app /usr/local/bin/替代直接gcc -o /usr/local/bin/app
排查 Windows 上的路径与权限陷阱
用 WSL 或 Cygwin 编译还好，但若在原生 Windows（尤其配了 gcc-arm-none-eabi）下遇到此错，大概率是路径惹的祸。
- 避免工具链装在
C:\Program Files\这类带空格或需提权的路径 ——make和gcc很多版本会把空格当分隔符，导致调用as.exe时参数断裂，最终表现为 “Permission denied” - 检查环境变量：
echo %PATH%看是否混入了 Windows 原生命令（如as或ld），覆盖了工具链自带的版本 - 若用 CMake，确认
CMAKE_C_COMPILER指向的是绝对路径（如C:/ARM_Toolchain/bin/arm-none-eabi-gcc.exe），而非依赖 PATH 查找
真正麻烦的不是权限本身，而是错误信息不指明具体哪个路径、哪个文件、哪一步失败。每次看到 “Permission denied”，先用 gcc -v 看完整执行链，再逐个检查 cc1 可执行性、输出目录所有权、以及路径中有没有空格或 Unicode 字符 —— 这三处占了九成以上的真实原因。
