我已经在Linux Mint 12上成功使用gcc。现在出现错误。我最近一直在进行一些.so编译并安装了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

说明

错误消息告诉我们，cc1未找到构建时依赖关系（在本例中为），因此我们所需要的只是将适当的软件包安装到系统中（使用软件包管理器//从源// //）

什么是cc1：

cc1是内部命令，用于获取预处理的C语言文件并将其转换为程序集。它是编译C的实际部分。对于C ++，有cc1plus和其他用于不同语言的内部命令。

^{摘自艾伦•舒特科（Alan Shutko）的回答。}

解决方案：Ubuntu / Linux Mint

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

解决方案：Docker-alpine环境

如果您在docker-alpine环境中，请通过将构建基础软件包添加到您的安装Dockerfile：

RUN apk add build-base

^{Pablo Castellano提供了更好的包装名称。更多细节在这里。}

如果您需要更多软件包来进行构建，请考虑添加alpine-sdk软件包：

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++ 

在debian / ubuntu上，我通过重新安装解决了此问题build-essential：

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

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

关于壳类型whereis cc1。如果cc1找到，最好继续在gcc; 目录中创建一个软链接。否则，cc1未安装，必须使用程序包管理器安装gcc-c ++。

Amazon Linux：修复GCC问题

由于这是Google的第一个结果，因此我只想记录一下我在Amazon Linux上的经验。安装gcc-c++.noarch修复了问题：

sudo yum install gcc-c++.noarch

有些人还报告了这种替代方法作为解决方案：

sudo yum install gcc72-c++

今天，我遇到了类似的问题-同事无法构建他的软件，但我可以构建它。他跑的gcc时候找不到cc1。

他的可执行路径看起来很合理，但是我无法轻松复制故障这一事实表明，他的环境中有某种原因。

最终，我们发现GCC_EXEC_PREFIX在他的环境中存在罪魁祸首，并且gcc在寻找中产生误导cc1。这是他的Shell启动脚本的一部分，旨在解决不再使用的SPARC / Solaris系统上的限制。通过不设置此环境变量解决了该问题。

http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html

我通过显式安装g ++解决了此问题：

sudo apt-get install g++

在安装熊猫时，在Ubuntu 12.04上遇到了问题。（感谢peribrarain。）

yum install gcc-c++ 做了修复。

确保您GCC_EXEC_PREFIX(env)未导出，并且PATH已导出到正确的工具链。

在RHEL 7上编译并安装了闪亮的新GCC（版本8.1）后，我很快就遇到了这种情况。我的根本原因是罪魁祸首。我最终发现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在我要求它进行编译时找到它！

如果您尝试在64位操作系统上运行32位gcc二进制文件并且缺少32位glibc，则这也可能是显示的错误消息。根据此自述文件：“对于64位系统，运行该工具需要32位libc和libncurses。” 在这种情况下，路径没有问题，实际上可以找到cc1，但是报告为缺少 32位glibc。

对我有用的是改为使用llvm-gcc：

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

仅记录我在此问题上的麻烦，即使它似乎只是其他答案的具体示例；作为一个相对新手，我觉得这可能会帮助其他人。

解：

我使用单个会话将“ / usr / bin”添加到PATH的开头，PATH='/usr/path/:$PATH'一切开始正常运行。

在确保它不会破坏常规工具链之后，我使用gedit永久更新了PATH。

说明：

我在Ubuntu 14.04LTS上安装了多个工具链，并且我经常只使用几个。当我尝试从命令行使用gcc时，出现了OP描述的问题。“ / usr / bin”在PATH中，但在其他工具链位置之后。原来，其他工具链的cc1与gcc不兼容。

只是为了补充@maxkoryukov关于高山的答案。

与Debian build-essential在Alpine中的等效build-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

您可以通过运行以下命令解决此问题：在Fedora上：

sudo dnf install redhat-rpm-config

我在相当新的Fedora 27上安装时遇到了这个问题。我尝试了所有其他建议或它们的等效建议。安装各种软件包时，要么说“已经安装”，要么安装了没有帮助的新东西。

固定于

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

在Scientific Linux 6上（类似于CentOS 6-SL现在已由CentOS，AIUI取代），我不得不使用/usr/sbin/prelink -av -mR我在https://stelfox.net/blog/2014/08/dependency-prelink-issues/上发现的建议

在这样做之前，gcc: error trying to exec 'cc1': execvp: No such file or directory尝试编译时遇到了cc1错误，尽管yum报告了该版本，但gcc --version报告的是4.2.2而不是4.4.7。

它可能相关，也可能不相关，但是系统在/ var上空间不足

在此软件包中（Ubuntu 19.04）：

  sudo apt install g++-6

在我极少数的情况下，是color wrapper谁宠坏了gcc。通过禁用从环境变量中cw排除其目录/usr/libexec/cw来解决PATH。

为什么会这样？当您安装Linux的新副本时，gcc编译器将随其预装。它仅包含用于运行linux的文件和二进制文件（显然可以节省空间和时间）。

如何解决这个错误？您需要做的就是通过软件包管理器更新软件包，然后重新安装基本构建软件包。在不同的内核上，命令可能不同。