Z powodzeniem używam gcc na Linux Mint 12. Teraz pojawia się błąd. Niedawno robiłem kompilacje .so i instalowałem Clang nie tak dawno, ale pomyślnie kompilowałem od czasu obu tych wydarzeń, więc nie jestem pewien, co się zmieniło. Użyłem Menedżera oprogramowania GUI, aby usunąć, a następnie ponownie zainstalować gcc, ale wyniki są takie same:

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

Wyjaśnienie

Komunikat o błędzie powiedział nam, że cc1nie znaleziono zależności czasu budowania (w tym przypadku jest ), więc wszystko czego potrzebujemy - zainstaluj odpowiedni pakiet w systemie (używając menedżera pakietów // ze źródeł // w inny sposób)

Co to jest cc1:

cc1to wewnętrzne polecenie, które pobiera wstępnie przetworzone pliki języka C i konwertuje je na assembler. Jest to właściwa część, która kompiluje C. Dla C ++ jest cc1plus i inne wewnętrzne polecenia dla różnych języków.

^{zaczerpnięte z tej odpowiedzi przez Alana Shutko .}

Rozwiązanie dla: Ubuntu / Linux Mint

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

Rozwiązanie dla: środowiska Docker-alpine

Jeśli pracujesz w środowisku docker-alpine, zainstaluj pakiet build-base , dodając do Dockerfile:

RUN apk add build-base

^{Lepszą nazwę pakietu podał Pablo Castellano . Więcej szczegółów tutaj .}

Jeśli potrzebujesz więcej pakietów do celów budowania, rozważ dodanie pakietu alpine-sdk :

RUN apk add alpine-sdk

^{Zaczerpnięte z github}

Rozwiązanie dla: CentOS / Fedora

Ta odpowiedź zawiera instrukcje dla CentOS i Fedora Linux

Rozwiązanie dla: Amazon Linux

sudo yum install gcc72-c++

^{Zrobione z tego komentarza przez CoderChris}

Możesz także spróbować zainstalować pominięte zależności w ten sposób ( chociaż mówi się, że nie rozwiązuje to problemu ):

sudo yum install gcc-c++.noarch

^{Zaczerpnięte z tej odpowiedzi}

W CentOS lub Fedorze

yum install gcc-c++ 

Na Debianie / Ubuntu naprawiłem ten problem poprzez ponowną instalację build-essential:

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

Dzieje się tak, ponieważ gccwywołuje wiele innych plików wykonywalnych w celu zakończenia przetwarzania danych wejściowych i cc1nie ma ich w dołączonej ścieżce.

Na typ muszli whereis cc1. Jeśli cc1zostanie znaleziony, lepiej idź dalej i utwórz miękki link w katalogu gcc; w przeciwnym razie cc1nie jest instalowany i musisz zainstalować gcc-c ++ za pomocą menedżera pakietów.

Amazon Linux: naprawa problemu z GCC

Ponieważ pojawia się to jako pierwszy wynik w Google, chciałem tylko udokumentować moje doświadczenia z Amazon Linux. Instalacja gcc-c++.noarchrozwiązała problem:

sudo yum install gcc-c++.noarch

Niektóre osoby również zgłosiły tę alternatywę jako rozwiązanie:

sudo yum install gcc72-c++

Dziś napotkałem podobny problem - współpracownik nie mógł zbudować swojego oprogramowania, ale mogłem je zbudować. Kiedy biegł, gccnie mógł znaleźćcc1 .

Jego wykonywalna ścieżka wyglądała rozsądnie, ale fakt, że nie mogłem łatwo odtworzyć awarii, sugerował coś w jego otoczeniu jako przyczynę.

W końcu znaleźliśmy GCC_EXEC_PREFIXw jego środowisku osobę odpowiedzialną za winowajcę i wprowadzającą gccw błąd podczas poszukiwań cc1. Było to częścią jego skryptów startowych powłoki i miało na celu obejście ograniczenia systemu SPARC / Solaris, który nie jest już używany. Problem został rozwiązany, nie ustawiając tej zmiennej środowiskowej.

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

Naprawiłem ten problem, jawnie instalując g ++:

sudo apt-get install g++

Wystąpił problem w systemie Ubuntu 12.04 podczas instalowania pand. (Dzięki perilbrain.)

yum install gcc-c++ naprawił.

Upewnij się, że GCC_EXEC_PREFIX(env)nie jest eksportowany, a PATHjest eksportowany do odpowiedniego łańcucha narzędzi.

Doświadczyłem tego wkrótce po skompilowaniu i zainstalowaniu nowego, błyszczącego GCC - wersja 8.1 - na RHEL 7. Ostatecznie skończyło się na problemie z uprawnieniami; mój główny umask był winowajcą. W końcu znalazłem cc1ukrywanie się w /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

Jednak uprawnienia do prowadzących tam katalogów nie pozwoliły na moje standardowe konto użytkownika:

[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

Szybkie rekurencyjne chmoddodawanie światowych uprawnień do odczytu / wykonywania naprawiło to:

[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

A teraz gccmogę znaleźć, cc1kiedy poproszę go o skompilowanie czegoś!

Może to być również wyświetlany komunikat o błędzie, jeśli próbujesz uruchomić 32-bitowe pliki binarne gcc w 64-bitowym systemie operacyjnym i brakuje 32-bitowej biblioteki glibc. Zgodnie z tym plikiem Readme : „W przypadku systemu 64-bitowego do uruchomienia narzędzi wymagane są 32-bitowe biblioteki libc i libncurses”. W tym przypadku nie ma problemu ze ścieżką, a cc1 jest faktycznie znalezione, ale zgłoszone jako brakujące jako brak 32-bitowego glibc.

Pomogło mi użycie llvm-gcczamiast tego:

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

Tylko po to, aby udokumentować mój problem z tym problemem, chociaż wydaje się, że jest to konkretny przykład innych odpowiedzi; jako względny nowicjusz czuję, że może to pomóc innym.

Rozwiązanie:

Dodałem '/ usr / bin' na początku PATH dla jednej sesji używając PATH='/usr/path/:$PATH'i wszystko zaczęło działać dobrze.

Użyłem gedit do trwałej aktualizacji PATH, po upewnieniu się, że nie zepsuje moich zwykłych łańcuchów narzędzi.

Wyjaśnienie:

Mam wiele łańcuchów narzędzi zainstalowanych w systemie Ubuntu 14.04LTS i regularnie używam tylko kilku. Kiedy próbowałem użyć gcc z wiersza poleceń, pojawił się problem opisany przez OP. '/ usr / bin' znajduje się w PATH, ale za innymi lokalizacjami toolchain. Okazuje się, że cc1 dla tych innych łańcuchów narzędzi jest niekompatybilne z gcc.

Żeby uzupełnić odpowiedź @ maxkoryukov dotyczącą Alpine.

Odpowiednikiem Debiana build-essentialw Alpine jest build-base. W rzeczywistości powyższe alpine-sdkzależy od 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

Możesz to naprawić, uruchamiając to: W Fedorze:

sudo dnf install redhat-rpm-config

Wystąpił ten problem podczas całkiem nowej instalacji Fedory 27. Wypróbowałem wszystkie inne sugestie lub ich odpowiedniki; instalowanie różnych pakietów mówiło „już zainstalowane” lub instalowało coś nowego, co nie pomogło.

Naprawiono za pomocą

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

W Scientific Linux 6 (podobnie jak CentOS 6-- SL jest teraz zastępowany przez CentOS, AIUI), musiałem użyć tego, /usr/sbin/prelink -av -mRco zostało zasugerowane na https://stelfox.net/blog/2014/08/dependency-prelink-issues/

Dopóki tego nie zrobiłem, pojawiał się błąd cc1, gcc: error trying to exec 'cc1': execvp: No such file or directorykiedy próbowałem kompilować, a gcc --version zgłosił 4.2.2 zamiast 4.4.7, mimo że wersja została zgłoszona przez yum.

Może być powiązany lub nie, ale w systemie zabrakło miejsca na / var

Jest w tym pakiecie (Ubuntu 19.04):

  sudo apt install g++-6

W moim rzadkim przypadku to color wrapperkto zepsuł gcc. Rozwiązany przez wyłączenie cwwykluczenia jego katalogu /usr/libexec/cwze PATHzmiennej środowiskowej.

Dlaczego to się dzieje? Kiedy instalujesz nową kopię Linuksa, prepakowany jest kompilator gcc. Zawiera tylko pliki i pliki binarne, które są używane do uruchamiania Linuksa (aby zaoszczędzić miejsce i czas, oczywiście).

Jak rozwiązać ten błąd? Wszystko, czego potrzebujesz, to zaktualizować pakiety za pośrednictwem menedżera pakietów i ponownie zainstalować pakiety niezbędne do kompilacji. Polecenia mogą być różne w różnych jądrach.