尝试执行‘ cc1’: Execvp: 没有这样的文件或目录

我已经成功地在 LinuxMint12上使用了 gcc。现在我得到了一个错误。我最近做了一些。所以构建和安装 Clang 不久之前,但已经成功编译,因为这两个事件,所以不确定有什么变化。我使用 GUI 软件管理器删除然后再次安装 gcc,但结果是相同的:

~/code/c/ut: which gcc
/usr/bin/gcc


~/code/c/ut: gcc -std=c99 -Wall -Wextra -g -c object.c
gcc: error trying to exec 'cc1': execvp: No such file or directory
356633 次浏览

这是因为 gcc调用许多其他可执行文件来完成输入的处理,而 cc1不在包含的路径中。

在外壳类型 whereis cc1上。如果找到了 cc1,那么最好在 gcc的目录中创建一个软链接; 否则,没有安装 cc1,您必须使用软件包管理器安装 Gcc-c + +

我今天遇到了一个类似的问题——一个同事不能构建他的软件,但是我可以构建它。当他运行 gcc时,它找不到 cc1

他的可执行路径看起来是合理的,但我不能轻易复制失败的事实表明,他的环境中存在某种因素。

最终,我们发现 GCC_EXEC_PREFIX定义在他的环境中,这是罪魁祸首,并在寻找 cc1的过程中误导了 gcc。这是他的 shell 启动脚本的一部分,旨在解决不再使用的 SPARC/Solaris 系统的限制。没有设置这个环境变量就解决了问题。

Http://gcc.gnu.org/onlinedocs/gcc/environment-variables.html

确保你的 GCC_EXEC_PREFIX(env)没有被导出,你的 PATH被导出到正确的工具链。

如果您试图在64位操作系统上运行32位 gcc 二进制文件,但是缺少32位 glibc,那么这也可能是显示的错误消息。根据这个 自述: “对于64位系统,需要32位 libc 和 libncurses 来运行这些工具。”. 在这种情况下,路径没有问题,实际上找到了 cc1,但是 报告失踪没有32位 glibc。

你可以通过运行以下命令来解决这个问题: 关于软呢帽:

sudo dnf install redhat-rpm-config

对我有帮助的是使用 llvm-gcc:

ln -s $(which llvm-gcc) /usr/local/bin/gcc

在 debian/ubuntu 上,我通过重新安装 build-essential解决了这个问题:

sudo apt-get update
sudo apt-get install --reinstall build-essential

我通过显式安装 g + + 来解决这个问题:

sudo apt-get install g++

Ubuntu12.04在安装熊猫时遇到了问题

解释

错误消息告诉我们,没有找到构建时依赖项(在本例中是 cc1) ,因此我们只需要ーー将适当的包安装到系统中(使用包管理器//from source//另一种方式)

什么是 cc1:

cc1是一个内部命令,它接受预处理的 C 语言文件并将它们转换为汇编文件。它是编译 C 的实际部分,对于 C + + ,有 cc1plus 和其他针对不同语言的内部命令。

摘自 Alan Shutko的答案。

解决方案: Ubuntu/Linux Mint

sudo apt-get update
sudo apt-get install --reinstall build-essential

解决方案: 码头-高山环境

如果你在 码头-阿尔卑斯山环境中安装 建立基础软件包,把它添加到你的 Dockerfile:

RUN apk add build-base

更好的软件包名称由 Pablo Castellano提供。更多的 详情请浏览此网页

如果你需要更多的软件包用于建筑目的,可以考虑添加 阿尔卑斯山软件包:

RUN apk add alpine-sdk

取自 Github

针对 CentOS/Fedora 的解决方案

这个答案 包含 CentOS 和 Fedora Linux 的说明

解决方案: Amazon Linux

sudo yum install gcc72-c++

取自 此评论CoderChris

您还可以尝试通过以下方法(不过,据说并没有解决这个问题)安装遗漏的依赖项:

sudo yum install gcc-c++.noarch

取自 这个答案

在 CentOS 或 Fedora 上

yum install gcc-c++

Amazon Linux: 修复 GCC 问题

由于这是谷歌的第一个搜索结果,我只想记录下我使用亚马逊 Linux 的经历。安装 gcc-c++.noarch解决了这个问题:

sudo yum install gcc-c++.noarch

一些人还报告说,这种替代办法是一种解决办法:

sudo yum install gcc72-c++

我在相当新鲜的 Fedora 27安装中遇到了这个问题。我尝试了所有其他的建议或类似的建议; 安装各种软件包,要么说“已经安装”,要么安装一些没有帮助的新软件包。

修好了

# dnf remove gcc
# dnf install gcc gcc-c++

yum install gcc-c++ 修好了。

在 Scientific Linux 6上(类似于 CentOS 6—— SL 现在被 CentOS,AIUI 所取代) ,我必须使用我在 https://stelfox.net/blog/2014/08/dependency-prelink-issues/上发现的建议的 /usr/sbin/prelink -av -mR

在此之前,我在尝试编译时得到了 cc1错误 gcc: error trying to exec 'cc1': execvp: No such file or directory,而 gcc —— version 报告的是4.2.2,而不是4.4.7,尽管 yum 报告了该版本。

它可能有关系,也可能没有关系,但是系统在/var 上已经用完了空间

只是为了记录我在这个问题上遇到的麻烦,即使它看起来只是其他答案的一个具体例子; 作为一个相对的新手,我觉得这可能会帮助其他人。

解决方案:

对于使用 PATH='/usr/path/:$PATH'的单个会话,我在 PATH 的开头添加了’/usr/bin’,一切都开始正常运行。

我使用 gedit 永久更新 PATH,确保它不会打破我的常规工具链。

说明:

我在 Ubuntu 14.04 LTS 上安装了多个工具链,并且我经常使用其中的一些工具链。当我试图从命令行使用 gcc 时,遇到了 OP 所描述的问题。“/usr/bin”位于 PATH 中,但它位于其他工具链位置的后面。其他工具链的 cc1与 gcc 不兼容。

我在 RHEL 7上编译并安装了一个崭新的 GCC ーー版本8.1ーー后不久就遇到了这种情况。最后,这成了一个权限问题; 我的根 umask 是罪魁祸首。我最终发现 cc1隐藏在 /usr/local/libexec中:

[root@nacelle gdb-8.1]# ls -l /usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/ | grep cc1
-rwxr-xr-x 1 root root 196481344 Jul  2 13:53 cc1

但是,目录的权限不允许我的标准用户帐户:

[root@nacelle gdb-8.1]# ls -l /usr/local/libexec/
total 4
drwxr-x--- 3 root root 4096 Jul  2 13:53 gcc
[root@nacelle gdb-8.1]# ls -l /usr/local/libexec/gcc/
total 4
drwxr-x--- 3 root root 4096 Jul  2 13:53 x86_64-pc-linux-gnu
[root@nacelle gdb-8.1]# ls -l /usr/local/libexec/gcc/x86_64-pc-linux-gnu/
total 4
drwxr-x--- 4 root root 4096 Jul  2 13:53 8.1.0

一个快速递归 chmod添加世界读/执行权限修复了它:

[root@nacelle 8.1.0]# cd /usr/local/libexec
[root@nacelle lib]# ls -l | grep gcc
drwxr-x---  3 root root     4096 Jul  2 13:53 gcc
[root@nacelle lib]# chmod -R o+rx gcc
[root@nacelle lib]# ls -l | grep gcc
drwxr-xr-x  3 root root     4096 Jul  2 13:53 gcc

现在,gcc可以找到 cc1当我要求它编译的东西!

只是为了补充@maxkoryukov 关于阿尔卑斯山的回答。

在阿尔卑斯山相当于 Debian 的 build-essentialbuild-base。事实上,上面提到的 alpine-sdk依赖于 build-base

/ # apk info -R build-base
build-base-0.5-r1 depends on:
binutils
file
gcc
g++
make
libc-dev
fortify-headers


/ # apk info -R alpine-sdk
alpine-sdk-1.0-r0 depends on:
abuild
build-base
git

它在这个包(Ubuntu 19.04)中:

  sudo apt install g++-6

在我罕见的情况下,是 color wrapper破坏了 gcc。通过从 PATH环境变量中禁用其目录 /usr/libexec/cw以外的 cw解决了这个问题。

为什么会这样? 当您安装一个新的 linux 副本时,gcc 编译器会预先包装它。它只包含用于运行 linux 的文件和二进制文件(显然是为了节省空间和时间)。

如何解决这个错误? 您所需要的只是通过包管理器更新您的包,并重新安装构建必需的包。 不同内核上的命令可能不同。

记录从源代码在 AmazonLinux2上安装 gcc-10的另一个错误源。

在运行 sudo make install并测试 gcc-10之后,我得到了这个错误:

gcc-10: fatal error: cannot execute ‘cc1’: execvp: No such file or directory

原因是 /usr/local/下的新 g + + 目录是由 sudo make install创建的,具有 700权限,因此非 root 用户无法查看目录内容。

我用跑的方式解决了

sudo find /usr/local/ -type d -exec chmod 755 {} \;

请注意,我遵循了这个代码片段 https://gist.github.com/nchaigne/ad06bc867f911a3c0d32939f1e930a11

亚马逊 Linux添加我的解决方案——在2021年工作:

sudo yum install gcc

然后:

sudo yum install gcc-c++

我罕见的情况下,PATH 变量被设置,但没有导出。 简单地导出 PATH 变量就可以解决这个问题。

我想补充一些额外的答案,对于那些谁最喜欢的答案没有帮助。

我不小心删除了 /usr/lib/usr/local/bin中的一些文件,所以 apt无法正确重新安装 gccbuild-essential包。我已经尝试了几乎所有的方法,但最终只是恢复了整个依赖树。在 Ubuntu 20.04上,我运行了以下命令:

sudo apt install --reinstall \
binutils \
binutils-common \
binutils-x86-64-linux-gnu \
cpp \
cpp-9 \
gcc \
gcc-10-base \
gcc-9 \
gcc-9-base \
libasan5 \
libatomic1 \
libbinutils \
libc-dev-bin \
libc6 \
libc6-dev \
libcc1-0 \
libcrypt-dev \
libcrypt1 \
libctf-nobfd0 \
libctf0 \
libgcc-9-dev \
libgcc-s1 \
libgmp10 \
libgomp1 \
libidn2-0 \
libisl22 \
libitm1 \
liblsan0 \
libmpc3 \
libmpfr6 \
libquadmath0 \
libstdc++6 \
libtsan0 \
libubsan1 \
libunistring2 \
linux-libc-dev \
manpages \
manpages-dev \
zlib1g

对于 亚马逊 Linux 发行版2来说,这将解决问题:

sudo yum install gcc-c++

(这不会工作: sudo yum install gcc72-c++)

举个例子,你可能发现你的 cc1安装在其他地方取决于之前安装的软件。

find /usr/ -name "*cc1*"
# out:  /usr/share/terminfo/x/xterm+pcc1
# out:  /usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1
# out: /usr/libexec/gcc/x86_64-redhat-linux/4.8.2/cc1plus
export PATH=$PATH:/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/

信贷属于规划者