gcc报Permission denied主因是文件无执行位或挂载含noexec；ld报该错多因-L指定目录而非库；gcc找不到cc1系libexecdir路径错误；宝塔/容器环境需检查用户权限、seccomp及SELinux策略。
gcc命令执行报Permission denied
这不是权限不足，而是gcc可执行文件本身被标记为不可执行，或所在目录有挂载限制（如noexec）。常见于手动解压二进制包、从非标准路径复制gcc、或挂载NTFS/exFAT分区后未设exec权限。
检查方式：ls -l $(which gcc) 看输出末尾是否含 x；再运行 mount | grep "$(dirname $(which gcc))" 查看对应挂载点是否含 noexec。
- 若权限缺失：用
chmod +x $(which gcc)修复（注意：需对gcc及其配套工具如cc1、ld一并处理） - 若挂载含
noexec：编辑/etc/fstab，删掉对应行的noexec选项，然后sudo mount -o remount /path/to/mount - Windows子系统（WSL）中从Windows侧复制的gcc：默认无执行位，必须
chmod +x，且不能放在/mnt/c/等跨区路径下直接运行
链接器ld报cannot find ...: Permission denied
错误里出现ld.exe: cannot find F:\Code Files\...\build: Permission denied，本质是链接器试图把输出路径当输入目标去读取——说明你误把目录路径写进了-l或-L参数，或CMake/Makefile里OUTPUT_DIRECTORY配置成了已存在的同名目录。
典型错误写法：g++ -L "F:\Code Files\project\build" ...，但build是空目录，不是库文件；或CMake中设了set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${CMAKE_BINARY_DIR}")，而${CMAKE_BINARY_DIR}和某个target名字冲突。
- 确认所有
-L后跟的是**包含.a/.so/.dll的目录**，不是构建输出目录 - 检查CMake中是否误用
add_subdirectory()导致target名与目录名重叠（尤其Linux下无.exe后缀时更易触发） - Windows路径含空格时，确保所有引号闭合且未被shell意外截断（比如cmd里双引号嵌套出错）
源码编译安装后gcc仍报execvp: No such file or directory
这表示gcc能启动，但找不到内部组件cc1。不是PATH问题，而是gcc安装时未正确设置libexecdir或libgcc路径硬编码失效。
查证方法：gcc -v hello.c 2>&1 | grep "libexec"，看它尝试加载cc1的路径是否存在、是否可执行。
- 若路径存在但无权限：
chmod -R +x /usr/lib/gcc/x86_64-linux-gnu/12.3.0/（版本号按实际替换） - 若路径不存在：重新configure时显式指定
--libexecdir=/usr/libexec/gcc，或安装后用ln -sf软链到真实位置 - 不要往
PATH里硬加lib目录——gcc不靠PATH找cc1，它依赖编译时内置的libexecdir
宝塔/容器环境里gcc提示Permission denied
这类环境常禁用exec能力，或以非root用户运行，导致即使文件有x权限也无法执行。
先确认进程上下文：ps aux | grep gcc看uid；再查seccomp或capabilities：cat /proc/$(pidof gcc)/status | grep CapEff。
- 宝塔面板：默认www用户无权执行编译工具，需在面板「安全」中放行
gcc、g++，或改用root用户终端操作 - Docker容器：启动时加
--cap-add=SYS_ADMIN或--security-opt seccomp=unconfined（仅测试用） - SELinux启用时：
setenforce 0临时关闭验证，若解决则需semanage fcontext -a -t bin_t "/path/to/gcc(/.*)?"并restorecon -Rv /path/to/gcc
cc1、as、ld这些底层工具的权限链或路径绑定。修完一个环节，记得用gcc -v -E /dev/null跑完整流程验证每一步是否可达。 
