Я успешно использую gcc на Linux Mint 12. Теперь я получаю сообщение об ошибке. Я недавно делал несколько сборок .so и не так давно установил Clang, но успешно скомпилировал после обоих этих событий, поэтому не уверен, что изменилось. Я использовал диспетчер программного обеспечения с графическим интерфейсом, чтобы удалить, а затем снова установить 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 и другие внутренние команды для разных языков.

^{взяты из этого ответа по Алан Шутко .}

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

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

Решение для: среды Docker-alpine

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

RUN apk add build-base

^{Лучшее название пакета предоставил Пабло Кастеллано . Подробнее здесь .}

Если вам нужно больше пакетов для сборки, рассмотрите возможность добавления пакета 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. Это было частью его сценариев запуска оболочки и предназначалось для обхода ограничения в системе SPARC / Solaris, которая больше не используется. Проблема была решена, если не задавать эту переменную среды.

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

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

sudo apt-get install g++

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

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

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

Я испытал это вскоре после компиляции и установки нового блестящего GCC - версии 8.1 - на RHEL 7. В конце концов, это оказалось проблемой с разрешениями; моя корневая маска была виновата. В конце концов я обнаружил, что 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когда прошу компилировать что-нибудь!

Это также может быть отображаемое сообщение об ошибке, если вы пытаетесь запустить 32-разрядные двоичные файлы gcc в 64-разрядной ОС и при этом отсутствует 32-разрядная glibc. Согласно этому файлу readme : «Для 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 относительно 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

Вы можете исправить это, запустив следующее: В 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/

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

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

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

  sudo apt install g++-6

В моем редком случае color wrapperбаловал именно тот gcc. Решается отключением cwисключения его каталога /usr/libexec/cwиз PATHпеременной окружения.

Почему это происходит? Когда вы устанавливаете новую копию linux, компилятор gcc поставляется с ней заранее. Он содержит только файлы и двоичные файлы, которые используются для запуска Linux (очевидно, для экономии места и времени).

Как решить эту ошибку? Все, что вам нужно, это обновить свои пакеты через диспетчер пакетов и переустановить пакеты, необходимые для сборки. Команды могут отличаться на разных ядрах.