Ответ 1

В debian/ubuntu я исправил эту проблему, переустановив build-essential:

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

Ответ 2

На CentOS или Fedora

yum install gcc-c++ 

Ответ 3

1. Объяснение

Сообщение об ошибке сообщило вам, что зависимость времени сборки (в данном случае это cc1) не была найдена, поэтому все, что вам нужно - установить соответствующий пакет в вашу систему (используя менеджер пакетов, сборку из исходных кодов или другим способом).

Что такое cc1:

cc1 - это внутренняя команда, которая берет предварительно обработанные файлы на языке C и преобразует их в сборку. Это фактическая часть, которая компилирует C. Для C++ есть cc1plus и другие внутренние команды для разных языков.

^{taken from this answer by Alan Shutko.}

Решение для: Ubuntu/Linux Mint

sudo apt-get install --reinstall build-essential

Решение для: Docker-alpine environment

Если вы находитесь в среде docker-alpine, установите пакет build-base, добавив его в Dockerfile:

RUN apk add build-base

^{Better package name provided by Pablo Castellano. More details here.}

Если вам нужно больше пакетов для сборки, рассмотрите возможность добавления пакета alpine-sdk :

RUN apk add alpine-sdk

^{Taken from github}

Решение для: Amazon Linux

sudo yum install gcc72-c++

^{Taken from this comment by CoderChris}

Вы также можете попытаться установить пропущенные зависимости следующим образом (хотя, как говорят, проблема не решается):

sudo yum install gcc-c++.noarch

^{Taken from this answer}

Ответ 4

Это связано с тем, что gcc вызывает много других исполняемых файлов для завершения обработки ввода, а cc1 не находится во включенном пути.

На тип оболочки, whereis cc1. Если cc1 найден, лучше создать софтлинк в каталоге gcc; в противном случае cc1 не устанавливается, и вы должны установить gcc-С++ с помощью менеджера пакетов.

Ответ 5

Amazon Linux: устранение проблемы GCC

Поскольку это первый результат в Google, я просто хотел документировать свой опыт работы с Amazon Linux. Установка gcc-c++.noarch исправил проблему:

sudo yum install gcc-c++.noarch

Некоторые люди также сообщили об этой альтернативе в качестве решения:

sudo yum install gcc72-c++

Ответ 6

Сегодня я столкнулся с подобной проблемой - сотрудник не смог создать свое программное обеспечение, но я мог бы его построить. Когда он побежал gcc, он не смог найти cc1.

Его исполняемый путь выглядел разумным, но тот факт, что я не мог легко воспроизвести неудачу, предложил что-то в его среде как причина.

В итоге мы обнаружили GCC_EXEC_PREFIX, определенный в его среде, который был виновником, и вводил в заблуждение gcc в поиске cc1. Это было частью его сценариев запуска оболочки и предназначалось для ограничения ограничений в системе SPARC/Solaris, которая больше не используется. Проблема была решена, если не установить эту переменную среды.

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

Ответ 7

Я исправил эту проблему, явно установив g++:

sudo apt-get install g++

Проблема возникла на Ubuntu 12.04 при установке pandas. (Спасибо perilbrain.)

Ответ 8

yum install gcc-c++  сделал исправление.

Ответ 9

Убедитесь, что ваш GCC_EXEC_PREFIX(env) не экспортирован, а ваш PATH экспортирован в правую цепочку инструментов.

Ответ 10

Я испытал это вскоре после компиляции и установки блестящего нового GCC - версии 8.1 - на RHEL 7. В конце концов, это оказалось проблемой с разрешениями; мой корневой umask был виновником. В итоге я обнаружил, что cc1 скрывается в /usr/local/libexec:

[[email protected] 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

Однако разрешения на каталоги, ведущие туда, не позволяли моей стандартной учетной записи пользователя:

[[email protected] gdb-8.1]# ls -l /usr/local/libexec/
total 4
drwxr-x--- 3 root root 4096 Jul  2 13:53 gcc
[[email protected] 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
[[email protected] 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 для добавления прав на чтение/выполнение в мире исправлено:

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

И теперь gcc может найти cc1 когда я попрошу его скомпилировать что-нибудь!

Ответ 11

Это может быть также отображаемое сообщение об ошибке, если вы пытаетесь запустить 32-разрядные двоичные файлы gcc в 64-разрядной ОС и пропустить 32-разрядный glibc. В соответствии с этим readme: "Для 64-разрядной системы для запуска инструментов требуются 32-разрядные libc и libncurses". В этом случае нет проблемы с контуром, и cc1 действительно найден, но сообщается как отсутствующий как 32-битный glibc.

Ответ 12

То, что помогло мне, заключалось в использовании llvm-gcc вместо этого:

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

Ответ 13

Просто для того, чтобы задокументировать мою проблему с этим вопросом, даже если это просто конкретный пример других ответов; как относительный новичок, я чувствую, что это может помочь другим.

Решение:

Я добавил /usr/bin в начало PATH для одного сеанса, используя PATH='/usr/path/:$PATH', и все начало работать нормально.

Я использовал gedit для постоянного обновления PATH, убедившись, что он не сломает мои обычные наборы инструментов.

Объяснение:

У меня установлено несколько наборов инструментов в Ubuntu 14.04LTS, и я регулярно использую только пару. Когда я попытался использовать gcc из командной строки, у меня возникла проблема, описанная OP. "/usr/bin" находится в PATH, но находится за другими местами цепочки инструментов. Оказывается, что cc1 для этих других наборов инструментов несовместим с gcc.

Ответ 14

Просто чтобы дополнить @maxkoryukov ответ по поводу Alpine.

Эквивалентом 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

Ответ 15

Вы можете исправить это, выполнив это: На Fedora:

sudo dnf install redhat-rpm-config

Ответ 16

Я испытал эту проблему на достаточно свежей установке Fedora 27. Я пробовал все другие предложения или их эквиваленты; устанавливая различные пакеты либо "уже установленные", либо устанавливая что-то новое, что не помогло.

Исправлено:

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

Ответ 17

На Scientific Linux 6 (аналогично CentOS 6-- SL теперь заменена CentOS, AIUI), мне пришлось использовать /usr/sbin/prelink -av -mR который я нашел в https://stelfox.net/blog/2014/08/зависимости Prelink-вопросы/

Пока я не сделал этого, у меня возникла ошибка cc1 gcc: error trying to exec 'cc1': execvp: No such file or directory когда я пытался скомпилировать, а gcc --version сообщил 4.2.2 вместо 4.4.7, несмотря на это версия сообщается yum.

Это может быть или не быть связано, но в системе не было места на /var

Ответ 18

Это в этом пакете (Ubuntu 19.04):

  sudo apt install g++-6