blocks|key|864122|text|这是因为gcc调用许多其他可执行文件来完成输入的处理，而cc1不在包含的路径中。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|864123|在shell类型whereis+cc1上。如果找到cc1，最好继续在gcc目录中创建一个软链接；否则，没有安装cc1，您必须使用包管理器安装gcc-c%2B%2B。|864124|entityMap^0|4|3|S|3|0|8|B|P|3|Y|3|1J|3|0^^$0|@$1|2|3|4|5|6|7|J|8|@$9|K|A|L|B|C]|$9|M|A|N|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|H|3|-4|5|6|7|X|8|@]|D|@]|E|$]]]|I|$]]

This is because <code>gcc</code> calls many other executables to complete the processing of the input, and <code>cc1</code> is not in the included path.

On shell type <code>whereis cc1</code>. If <code>cc1</code> is found, it's better go ahead and create a softlink in the directory of <code>gcc</code>; otherwise, <code>cc1</code> is not installed and you have to install gcc-c++ using the package manager.

blocks|key|862450|text|我今天遇到了一个类似的问题--一个同事不能构建他的软件，但我可以构建它。当他运行gcc时，它找不到cc1。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|862451|他的可执行路径看起来是合理的，但我无法轻易复制失败的事实表明，在他的环境中，原因是什么。|862452|最后，我们发现了在他的环境中定义的GCC_EXEC_PREFIX，这是罪魁祸首，并且在搜索cc1时误导了gcc。这是他的shell启动脚本的一部分，目的是在不再使用的SPARC/Solaris系统上进行限制。通过不设置此环境变量解决了问题。|862453|http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html|862454|entityMap|0|LINK|mutability|MUTABLE|url^0|14|3|1D|3|0|0|H|F|19|3|1G|3|0|0|1O|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@$9|T|A|U|B|C]|$9|V|A|W|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|X|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|Y|8|@$9|Z|A|10|B|C]|$9|11|A|12|B|C]|$9|13|A|14|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|15|8|@]|D|@$9|16|A|17|1|18]]|E|$]]|$1|L|3|-4|5|6|7|19|8|@]|D|@]|E|$]]]|M|$N|$5|O|P|Q|E|$R|K]]]]

I ran into a similar issue today - a co-worker could not build his software but I could build it. When he ran <code>gcc</code> it could not find <code>cc1</code>.

His executable path looked reasonable but the fact that I could not easily replicate the failure suggested something in his environment as the cause.

Eventually we found <code>GCC_EXEC_PREFIX</code> defined in his environment which was the culprit and was misleading <code>gcc</code> in the search for <code>cc1</code>. This was part of his shell startup scripts and was meant to work around a limitation on a SPARC/Solaris system that is no longer in use. The problem was resolved by not setting this environment variable.

<a href="http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html" rel="noreferrer">http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html</a>

blocks|key|1264049|text|确保您的GCC_EXEC_PREFIX(env)没有导出，并且您的PATH被导出到正确的工具链。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1264050|entityMap^0|4|K|X|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|M|8|@]|D|@]|E|$]]]|G|$]]

Make sure your <code>GCC_EXEC_PREFIX(env)</code> is not exported and your <code>PATH</code> is exported to right tool chain.

blocks|key|1741452|text|如果您尝试在64位操作系统上运行32位gcc二进制文件而缺少32位glibc，这也可能是显示的错误消息。根据这个自述文件：“对于64位系统，运行这些工具需要32位libc和libncurse。”在本例中，路径没有问题，并且实际上找到了cc1，但是据报失踪没有32位glibc。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1741453|entityMap|0|LINK|mutability|MUTABLE|url|https://launchpadlibrarian.net/174121181/readme.txt|1|https://stackoverflow.com/questions/2716702/no-such-file-or-directory-error-when-executing-a-binary^0|1K|4|0|3F|4|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

This might also be the displayed error message if you try to run 32-bit gcc binaries on a 64-bit OS and missing 32-bit glibc. According to this <a href="https://launchpadlibrarian.net/174121181/readme.txt" rel="nofollow noreferrer">readme</a>: "For 64 bit system, 32 bit libc and libncurses are required to run the tools.".
In this case there is no problem with the path and cc1 is actually found, but <a href="https://stackoverflow.com/questions/2716702/no-such-file-or-directory-error-when-executing-a-binary">reported as missing</a> as no 32 bit glibc.

blocks|key|1741480|text|您可以通过在Fedora上运行以下命令来解决这个问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741481|sudo+dnf+install+redhat-rpm-config|code-block|syntax|javascript|1741482|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

You can fix that by running this:
On Fedora:

<pre><code>sudo dnf install redhat-rpm-config
</code></pre>

blocks|key|1264164|text|对我有帮助的是使用llvm-gcc来代替：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1264165|ln+-s+$(which+llvm-gcc)+/usr/local/bin/gcc|code-block|syntax|javascript|1264166|entityMap^0|9|8|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

What helped for me was to use <code>llvm-gcc</code> instead:

<pre><code>ln -s $(which llvm-gcc) /usr/local/bin/gcc
</code></pre>

blocks|key|1264183|text|在debian+/+ubuntu上，我通过重新安装build-essential解决了这个问题|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1264184|sudo+apt-get+update
sudo+apt-get+install+--reinstall+build-essential|code-block|syntax|javascript|1264185|entityMap^0|P|F|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@$9|N|A|O|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|P|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|Q|8|@]|D|@]|E|$]]]|L|$]]

On debian / ubuntu I fixed this problem by reinstalling <code>build-essential</code>:

<pre><code>sudo apt-get update
sudo apt-get install --reinstall build-essential
</code></pre>

blocks|key|1741536|text|我通过显式安装g%2B%2B解决了这个问题：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741537|sudo+apt-get+install+g%2B%2B|code-block|syntax|javascript|1741538|Ubuntu12.04在安装熊猫时遇到了问题。(谢谢后脑。)|1741539|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I fixed this problem by explicitly installing g++:

<pre><code>sudo apt-get install g++
</code></pre>

Problem was encountered on Ubuntu 12.04 while installing pandas. (Thanks perilbrain.)

blocks|key|1741552|text|论CentOS或Fedora|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741553|yum+install+gcc-c%2B%2B+|code-block|syntax|javascript|1741554|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

On CentOS or Fedora

<pre><code>yum install gcc-c++ 
</code></pre>

blocks|key|862561|text|Amazon+:修正GCC问题|type|blockquote|depth|inlineStyleRanges|entityRanges|data|862562|由于这是Google上的第一个结果，我只想记录一下我在Amazon上的经验。安装gcc-c%2B%2B.noarch修复了问题：|unstyled|offset|length|style|CODE|862563|sudo+yum+install+gcc-c%2B%2B.noarch|862564|一些人还报告说，这种替代办法是一种解决办法：|862565|sudo+yum+install+gcc72-c%2B%2B|862566|entityMap^0|0|14|E|0|0|V|0|0|0|Q|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|R|8|@$E|S|F|T|G|H]]|9|@]|A|$]]|$1|I|3|J|5|D|7|U|8|@$E|V|F|W|G|H]]|9|@]|A|$]]|$1|K|3|L|5|D|7|X|8|@]|9|@]|A|$]]|$1|M|3|N|5|D|7|Y|8|@$E|Z|F|10|G|H]]|9|@]|A|$]]|$1|O|3|-4|5|D|7|11|8|@]|9|@]|A|$]]]|P|$]]

<blockquote>
 <h1>Amazon Linux: fixing GCC issue</h1>
</blockquote>

Since this comes up as the first result on Google, I just wanted to document my experience with Amazon Linux. Installing <code>gcc-c++.noarch</code> fixed the problem:

<code>sudo yum install gcc-c++.noarch</code>

Some people also reported this alternative as a solution:

<code>sudo yum install gcc72-c++</code>

blocks|key|1264314|text|我在一个相当新鲜的Fedora+27安装中遇到了这个问题。我尝试了所有其他建议或它们的等价物；安装不同的软件包，要么说“已经安装”，要么安装一些没有帮助的新东西。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1264315|固定在|1264316|#+dnf+remove+gcc
#+dnf+install+gcc+gcc-c%2B%2B|code-block|syntax|javascript|1264317|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

I experienced this problem on a reasonably fresh install of Fedora 27. I tried all the other suggestions or their equivalents; installing the various packages either said "already installed" or installed something new which didn't help.

Fixed with

<pre><code># dnf remove gcc
# dnf install gcc gcc-c++
</code></pre>

blocks|key|862588|text|yum+install+gcc-c%2B%2B做了修复。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|862589|entityMap^0|0|J|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|K|8|@]|D|@]|E|$]]]|G|$]]

<code>yum install gcc-c++</code> 
 did the fix.

blocks|key|862600|text|在科学Linux+6上(类似于CentOS+6-+SL现在被CentOS，AIUI所取代)，我不得不使用/usr/sbin/prelink+-av+-mR，这是我在https://stelfox.net/blog/2014/08/dependency-prelink-issues/上建议的。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|862601|在我这么做之前，我尝试编译时得到了一个cc1错误gcc:+error+trying+to+exec+'cc1':+execvp:+No+such+file+or+directory，gcc版本报告了4.2.2而不是4.4.7，尽管那个版本是由yum报告的。|862602|它可能是相关的，也可能不是相关的，但是系统在/var上已经耗尽了空间。|862603|entityMap|0|LINK|mutability|MUTABLE|url|https://stelfox.net/blog/2014/08/dependency-prelink-issues/^0|1G|P|2A|1N|0|0|O|1U|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]]|D|@$9|U|A|V|1|W]]|E|$]]|$1|F|3|G|5|6|7|X|8|@$9|Y|A|Z|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|10|8|@]|D|@]|E|$]]|$1|J|3|-4|5|6|7|11|8|@]|D|@]|E|$]]]|K|$L|$5|M|N|O|E|$P|Q]]]]

On Scientific Linux 6 (similar to CentOS 6-- SL is now replaced by CentOS, AIUI), I had to use <code>/usr/sbin/prelink -av -mR</code> which I found suggested at <a href="https://stelfox.net/blog/2014/08/dependency-prelink-issues/" rel="nofollow noreferrer">https://stelfox.net/blog/2014/08/dependency-prelink-issues/</a>

Until I did that, I got a cc1 error <code>gcc: error trying to exec 'cc1': execvp: No such file or directory</code> when I tried to compile, and gcc --version reported 4.2.2 instead of 4.4.7, despite that version being reported by yum.

It may or may not be related, but the system had run out of space on /var

blocks|key|1741737|text|只是为了记录我在这个问题上的麻烦，尽管它似乎只是其他答案的一个具体例子；作为一个相对新手，我觉得这可能会对其他人有所帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741738|解决方案：|1741739|我在使用PATH='/usr/path/:$PATH'的单个会话的路径开头添加了'/usr/bin‘，一切都开始正常工作。|offset|length|style|CODE|1741740|在确保路径不会破坏我的常规工具链之后，我使用gedit永久更新路径。|1741741|解释：|1741742|我在Ubuntu14.04LTS上安装了多个工具链，并且我定期使用几个工具链。当我试图在命令行中使用gcc时，我得到了OP描述的问题。'/usr/bin‘在路径中，但它位于其他工具链位置的后面。事实证明，其他工具链的cc1与gcc不兼容。|1741743|entityMap^0|0|0|4|N|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|T|8|@$F|U|G|V|H|I]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|X|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

Just to document my trouble with this issue even though it just appears to be a specific example of other answers; as a relative newbie I feel like this might help others. 

Solution:

I added '/usr/bin' to the beginning of PATH for a single session using <code>PATH='/usr/path/:$PATH'</code> and everything started to work fine. 

I used gedit to update the PATH permanently, after ensuring it wouldn't break my regular toolchains.

Explanation:

I have multiple toolchains installed on Ubuntu 14.04LTS and I use just a couple on a regular basis. When I tried to use gcc from the command line I got the issue describe by the OP. '/usr/bin' is in the PATH but it is behind the other toolchain locations. Turns out the cc1 for those other toolchains is incompatible with gcc.

blocks|key|1264410|text|在RHEL+7上编译和安装了一个闪亮的GCC版本8.1之后，我很快就体验到了这一点。最后，它最终变成了一个权限问题；我的根umask就是罪魁祸首。我最终发现cc1藏在/usr/local/libexec里|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1264411|[root@nacelle+gdb-8.1]#+ls+-l+/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.1.0/+%7C+grep+cc1
-rwxr-xr-x+1+root+root+196481344+Jul++2+13:53+cc1|code-block|syntax|javascript|1264412|但是，导致这些目录的权限不允许我的标准用户帐户：|1264413|[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|1264414|添加world+read/execute权限的快速递归chmod立即将其修复：|1264415|[root@nacelle+8.1.0]#+cd+/usr/local/libexec
[root@nacelle+lib]#+ls+-l+%7C+grep+gcc
drwxr-x---++3+root+root+++++4096+Jul++2+13:53+gcc
[root@nacelle+lib]#+chmod+-R+o%2Brx+gcc
[root@nacelle+lib]#+ls+-l+%7C+grep+gcc
drwxr-xr-x++3+root+root+++++4096+Jul++2+13:53+gcc|1264416|现在，当我要求gcc编译一些东西时，它可以找到cc1！|1264417|entityMap^0|26|3|2B|I|0|0|0|0|R|5|0|0|7|3|N|3|0^^$0|@$1|2|3|4|5|6|7|W|8|@$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|11|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|12|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|13|8|@]|D|@]|E|$I|J]]|$1|O|3|P|5|6|7|14|8|@$9|15|A|16|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|H|7|17|8|@]|D|@]|E|$I|J]]|$1|S|3|T|5|6|7|18|8|@$9|19|A|1A|B|C]|$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1D|8|@]|D|@]|E|$]]]|V|$]]

I experienced this soon after compiling and installing a shiny new GCC — version 8.1 — on RHEL 7. In the end, it ended up being a permissions problem; my root umask was the culprit. I eventually found <code>cc1</code> hiding in <code>/usr/local/libexec</code>:

<pre><code>[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
</code></pre>

However, the permissions on the directories leading there didn't allow my standard user account:

<pre><code>[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
</code></pre>

A quick recursive <code>chmod</code> to add world read/execute permissions fixed it right up:

<pre><code>[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
</code></pre>

And now <code>gcc</code> can find <code>cc1</code> when I ask it to compile something!

blocks|key|1741802|text|只是为了补充@maxkoryukov关于阿尔卑斯的回答。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741803|在阿尔卑斯山，与Debian的build-essential等价的是build-base。事实上，上面提到的alpine-sdk依赖于build-base。|offset|length|style|CODE|1741804|/+#+apk+info+-R+build-base
build-base-0.5-r1+depends+on:
binutils
file
gcc
g%2B%2B
make
libc-dev
fortify-headers

/+#+apk+info+-R+alpine-sdk
alpine-sdk-1.0-r0+depends+on:
abuild
build-base
git|code-block|syntax|javascript|1741805|entityMap^0|0|F|F|Y|A|1I|A|1V|A|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]|$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|Y|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|N|$]]

Just to complement @maxkoryukov's answer regarding Alpine.

The equivalent to Debian's <code>build-essential</code> in Alpine is <code>build-base</code>. In fact, the above mentioned <code>alpine-sdk</code> depends on <code>build-base</code>.

<pre><code>/ # 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
</code></pre>

blocks|key|1264479|text|它在这个软件包中(Ubuntu+19.04)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1264480|++sudo+apt+install+g%2B%2B-6|code-block|syntax|javascript|1264481|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|I|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|J|8|@]|9|@]|A|$E|F]]|$1|G|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|H|$]]

It's in this package (Ubuntu 19.04): 

<pre><code> sudo apt install g++-6
</code></pre>

blocks|key|1741816|text|在我罕见的情况下，是color+wrapper宠坏了gcc。通过禁用cw+(将其目录/usr/libexec/cw排除在PATH环境变量之外)来解决问题。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1741817|entityMap^0|A|D|Q|3|Y|2|16|F|1O|4|0^^$0|@$1|2|3|4|5|6|7|H|8|@$9|I|A|J|B|C]|$9|K|A|L|B|C]|$9|M|A|N|B|C]|$9|O|A|P|B|C]|$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|-4|5|6|7|S|8|@]|D|@]|E|$]]]|G|$]]

In my rare case it was <code>color wrapper</code> who spoiled <code>gcc</code>. Solved by disabling <code>cw</code> excluding its directory <code>/usr/libexec/cw</code> from <code>PATH</code> environmental variable.

blocks|key|1264506|text|这一切为什么要发生？当你安装一个新的linux拷贝时，gcc编译器预装了它.它只包含用于运行linux的文件和二进制文件(显然是为了节省空间和时间)。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1264507|如何解决这个错误？您所需要的只是通过包管理器更新您的包，并重新安装构建必需的包。不同内核上的命令可能不同。|1264508|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Why does this happen?
When you install a fresh copy of linux, gcc compiler comes pre-packed with it. It only contains the files and binaries which are used to run the linux(to save space and time, obviously).
How to solve this error?
All you need is to update your packages through the package manager and reinstall the build-essential packages.
The commands might be different on different kernels.

blocks|key|1264536|text|从源代码中记录在Amazon+2上安装gcc-10的另一个错误源。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1264537|在运行sudo+make+install并测试gcc-10之后，我得到了以下错误：|offset|length|style|CODE|1264538|gcc-10:+fatal+error:+cannot+execute+‘cc1’:+execvp:+No+such+file+or+directory|code-block|syntax|javascript|1264539|原因是/usr/local/下的新/usr/local/目录是由sudo+make+install创建的，具有700权限，因此非根用户无法查看目录内容。|1264540|我通过跑来修复它|1264541|sudo+find+/usr/local/+-type+d+-exec+chmod+755+{}+\;|1264542|请注意，我遵循了这个片段https://gist.github.com/nchaigne/ad06bc867f911a3c0d32939f1e930a11|1264543|entityMap|0|LINK|mutability|MUTABLE|url|https://gist.github.com/nchaigne/ad06bc867f911a3c0d32939f1e930a11^0|0|3|H|N|6|0|0|3|B|H|B|W|H|1J|3|0|0|0|C|1T|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@$D|14|E|15|F|G]|$D|16|E|17|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|18|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|19|8|@$D|1A|E|1B|F|G]|$D|1C|E|1D|F|G]|$D|1E|E|1F|F|G]|$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|O|3|P|5|6|7|1I|8|@]|9|@]|A|$]]|$1|Q|3|R|5|J|7|1J|8|@]|9|@]|A|$K|L]]|$1|S|3|T|5|6|7|1K|8|@]|9|@$D|1L|E|1M|1|1N]]|A|$]]|$1|U|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]]|V|$W|$5|X|Y|Z|A|$10|11]]]]

Documenting another source of errors for installing gcc-10 on Amazon Linux 2 from source.
After running <code>sudo make install</code> and then testing <code>gcc-10</code> I got this error:
<pre><code>gcc-10: fatal error: cannot execute ‘cc1’: execvp: No such file or directory
</code></pre>
The reason was that the new g++ directories under <code>/usr/local/</code> were created by <code>sudo make install</code> have <code>700</code> permissions so non-root users cannot see the directories content.
I fixed it by running
<pre><code>sudo find /usr/local/ -type d -exec chmod 755 {} \;
</code></pre>
Note that I followed this snippet <a href="https://gist.github.com/nchaigne/ad06bc867f911a3c0d32939f1e930a11" rel="nofollow noreferrer">https://gist.github.com/nchaigne/ad06bc867f911a3c0d32939f1e930a11</a>

blocks|key|864364|text|为Amazon+添加我的解决方案--2021年开始工作：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|864365|sudo+yum+install+gcc|code-block|syntax|javascript|864366|然后：|864367|sudo+yum+install+gcc-c%2B%2B|864368|entityMap^0|1|7|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@$9|R|A|S|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|T|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|U|8|@]|D|@]|E|$]]|$1|M|3|N|5|H|7|V|8|@]|D|@]|E|$I|J]]|$1|O|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|P|$]]

Adding my solution for Amazon Linux - Working in 2021:
<pre><code>sudo yum install gcc
</code></pre>
and then:
<pre><code>sudo yum install gcc-c++
</code></pre>

blocks|key|1741881|text|Im是我的罕见情况，路径变量被设置，但没有导出。简单地导出路径变量就是为了解决这个问题。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741882|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Im my rare case the PATH variable was set but not exported.
Simply exporting the PATH variable was solving this problem.

blocks|key|1741900|text|我想补充一些额外的答案，因为那些最喜欢的答案没有帮助。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1741901|我意外地删除了/usr/lib和/usr/local/bin中的一些文件，因此apt无法正确地重新安装gcc和build-essential包。我已经尝试了几乎所有的东西，但是最后，只有恢复整个依赖树才有所帮助。在Ubuntu20.04上，我运行了以下命令：|offset|length|style|CODE|1741902|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%2B%2B6+\
++++libtsan0+\
++++libubsan1+\
++++libunistring2+\
++++linux-libc-dev+\
++++manpages+\
++++manpages-dev+\
++++zlib1g|code-block|syntax|javascript|1741903|entityMap^0|0|7|8|G|E|13|3|1F|3|1J|F|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|P|8|@$D|Q|E|R|F|G]|$D|S|E|T|F|G]|$D|U|E|V|F|G]|$D|W|E|X|F|G]|$D|Y|E|Z|F|G]]|9|@]|A|$]]|$1|H|3|I|5|J|7|10|8|@]|9|@]|A|$K|L]]|$1|M|3|-4|5|6|7|11|8|@]|9|@]|A|$]]]|N|$]]

I would like to add some additional answer, for the ones who the most liked answer didn't help.
I accidentally deleted some of files in <code>/usr/lib</code> and <code>/usr/local/bin</code> so <code>apt</code> couldn't reinstall <code>gcc</code> and <code>build-essential</code> packages correctly. I've tried almost everything, but, at the end only restoring the whole dependency tree helped. On Ubuntu 20.04 I've run the following:
<pre><code>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
</code></pre>

blocks|key|1264614|text|对于Amazon第2版，这将解决以下问题：|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|1264615|sudo+yum+install+gcc-c%2B%2B|code-block|syntax|javascript|1264616|(这不起作用：sudo+yum+install+gcc72-c%2B%2B)|CODE|1264617|entityMap^0|2|9|0|0|7|Q|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|S|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|T|8|@$9|U|A|V|B|M]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|W|8|@]|D|@]|E|$]]]|O|$]]

For Amazon Linux Release 2 This will solve the issue:
<pre><code>sudo yum install gcc-c++
</code></pre>
(This will not work: <code>sudo yum install gcc72-c++</code>)

blocks|key|1264646|text|举个例子。您可能会发现您在其他地方安装的cc1取决于以前安装的软件。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1264647|find+/usr/+-name+"*cc1*"
#+out:++/usr/share/terminfo/x/xterm%2Bpcc1
#+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/|code-block|syntax|javascript|1264648|信用属于程序|1264649|https://programmerah.com/gcc-error-trying-to-exec-cc1-execvp-no-such-file-or-directory-27405/|unordered-list-item|1264650|https://programmerah.com/solved-gcc-error-trying-to-exec-cc1-execvp-no-such-file-or-directory-51267/|1264651|entityMap|0|LINK|mutability|MUTABLE|url|1^0|K|3|0|0|0|0|2L|0|0|0|2S|1|0^^$0|@$1|2|3|4|5|6|7|Z|8|@$9|10|A|11|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|12|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|13|8|@]|D|@]|E|$]]|$1|M|3|N|5|O|7|14|8|@]|D|@$9|15|A|16|1|17]]|E|$]]|$1|P|3|Q|5|O|7|18|8|@]|D|@$9|19|A|1A|1|1B]]|E|$]]|$1|R|3|-4|5|6|7|1C|8|@]|D|@]|E|$]]]|S|$T|$5|U|V|W|E|$X|N]]|Y|$5|U|V|W|E|$X|Q]]]]

Just an example. You might find your <code>cc1</code> installed on other places depends on whatever software was installed before.
<pre><code>find /usr/ -name &quot;*cc1*&quot;
# 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/
</code></pre>
credit belong to programmerah
<ul>
<li><a href="https://programmerah.com/gcc-error-trying-to-exec-cc1-execvp-no-such-file-or-directory-27405/" rel="nofollow noreferrer">https://programmerah.com/gcc-error-trying-to-exec-cc1-execvp-no-such-file-or-directory-27405/</a></li>
<li><a href="https://programmerah.com/solved-gcc-error-trying-to-exec-cc1-execvp-no-such-file-or-directory-51267/" rel="nofollow noreferrer">https://programmerah.com/solved-gcc-error-trying-to-exec-cc1-execvp-no-such-file-or-directory-51267/</a></li>
</ul>

I have been successfully using gcc on Linux Mint 12. Now I am getting an error. I have recently been doing some .so builds and installed Clang not to long ago, but have successfully compiled since both of those events, so not sure what has changed. I used the GUI Software Manager to remove and then install gcc again, but the results are the same:

<pre><code>~/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
</code></pre>

Gcc error: gcc: error trying to exec 'cc1': execvp: No such file or directory

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋 

腾讯云代码助手

CODING DevOps

Cloud Studio

SDK中心

API中心

命令行工具

我在Linux 12上成功地使用了gcc，现在我收到了一个错误。不久前，我已经做了一些.so构建并安装了Clang，但是在这两个事件之后我已经成功地编译了，所以不确定什么已经改变了。我使用GUI软件管理器删除并重新安装gcc，但是结果是相同的：~/code/c/ut: which gcc                ...

问Gcc错误: gcc:试图执行“cc1”的错误: execvp:没有这样的文件或目录
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Gcc错误: gcc:试图执行“cc1”的错误: execvp:没有这样的文件或目录EN