Sto usando con successo gcc su Linux Mint 12. Ora ricevo un errore. Recentemente ho eseguito alcune build .so e ho installato Clang non molto tempo fa, ma ho compilato con successo dopo entrambi gli eventi, quindi non sono sicuro di cosa sia cambiato. Ho usato la GUI Software Manager per rimuovere e poi installare di nuovo gcc, ma i risultati sono gli stessi:

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

Spiegazione

Il messaggio di errore ci diceva che la dipendenza del tempo di compilazione (in questo caso lo è cc1) non è stata trovata, quindi tutto ciò di cui abbiamo bisogno - installa il pacchetto appropriato sul sistema (usando il gestore di pacchetti // dalle fonti // in un altro modo)

Che cos'è cc1:

cc1è il comando interno che prende i file in linguaggio C preelaborati e li converte in assembly. È la parte effettiva che compila C. Per C ++, ci sono cc1plus e altri comandi interni per linguaggi diversi.

^{tratto da questa risposta di Alan Shutko .}

Soluzione per: Ubuntu / Linux Mint

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

Soluzione per: ambiente Docker-alpino

Se ti trovi in un ambiente docker-alpine , installa il pacchetto build-base aggiungendolo a Dockerfile:

RUN apk add build-base

^{Nome del pacchetto migliore fornito da Pablo Castellano . Maggiori dettagli qui .}

Se hai bisogno di più pacchetti per scopi di costruzione, considera l'aggiunta del pacchetto alpine-sdk :

RUN apk add alpine-sdk

^{Tratto da GitHub}

Soluzione per: CentOS / Fedora

Questa risposta contiene le istruzioni per CentOS e Fedora Linux

Soluzione per: Amazon Linux

sudo yum install gcc72-c++

^{Tratto da questo commento di CoderChris}

Puoi anche provare a installare le dipendenze perse con questo ( tuttavia, si dice che non risolva il problema ):

sudo yum install gcc-c++.noarch

^{Tratto da questa risposta}

Su CentOS o Fedora

yum install gcc-c++ 

Su debian / ubuntu ho risolto questo problema reinstallando build-essential:

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

Questo perché gccchiama molti altri eseguibili per completare l'elaborazione dell'input e cc1non è nel percorso incluso.

Sul tipo di shell whereis cc1. Se cc1viene trovato, è meglio andare avanti e creare un softlink nella directory di gcc; altrimenti, cc1non è installato e devi installare gcc-c ++ usando il gestore dei pacchetti.

Amazon Linux: risoluzione del problema di GCC

Poiché questo si presenta come il primo risultato su Google, volevo solo documentare la mia esperienza con Amazon Linux. L'installazione ha gcc-c++.noarchrisolto il problema:

sudo yum install gcc-c++.noarch

Alcune persone hanno anche segnalato questa alternativa come soluzione:

sudo yum install gcc72-c++

Oggi ho riscontrato un problema simile: un collega non poteva costruire il suo software ma io potevo crearlo. Quando correva gccnon riusciva a trovare cc1.

Il suo percorso eseguibile sembrava ragionevole, ma il fatto che non potessi replicare facilmente il fallimento suggeriva qualcosa nel suo ambiente come causa.

Alla fine abbiamo trovato GCC_EXEC_PREFIXdefinito nel suo ambiente quale fosse il colpevole ed era fuorviante gccnella ricerca cc1. Questo faceva parte dei suoi script di avvio della shell ed era pensato per aggirare una limitazione su un sistema SPARC / Solaris che non è più in uso. Il problema è stato risolto non impostando questa variabile di ambiente.

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

Ho risolto questo problema installando esplicitamente g ++:

sudo apt-get install g++

Si è verificato un problema su Ubuntu 12.04 durante l'installazione dei panda. (Grazie perilbrain.)

yum install gcc-c++ ha fatto la correzione.

Assicurati che il tuo GCC_EXEC_PREFIX(env)non sia esportato e che il tuo PATHsia esportato nella giusta catena di strumenti.

L'ho sperimentato subito dopo aver compilato e installato un nuovo brillante GCC - versione 8.1 - su RHEL 7. Alla fine, si è rivelato un problema di autorizzazioni; il mio root umask era il colpevole. Alla fine ho trovato cc1nascosto in /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

Tuttavia, le autorizzazioni sulle directory che conducono lì non consentivano il mio account utente standard:

[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

Un rapido ricorsivo chmodper aggiungere i permessi di lettura / esecuzione del mondo lo ha risolto:

[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

E ora gccposso trovare cc1quando gli chiedo di compilare qualcosa!

Questo potrebbe anche essere il messaggio di errore visualizzato se si tenta di eseguire binari gcc a 32 bit su un sistema operativo a 64 bit e glibc a 32 bit mancante. Secondo questo file readme : "Per il sistema a 64 bit, sono necessarie libc e libncurses a 32 bit per eseguire gli strumenti.". In questo caso non ci sono problemi con il percorso e cc1 viene effettivamente trovato, ma segnalato come mancante come non glibc a 32 bit.

Ciò che mi ha aiutato è stato utilizzare llvm-gccinvece:

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

Solo per documentare i miei problemi con questo problema anche se sembra essere un esempio specifico di altre risposte; come un principiante relativo, sento che questo potrebbe aiutare gli altri.

Soluzione:

Ho aggiunto "/ usr / bin" all'inizio di PATH per una singola sessione utilizzando PATH='/usr/path/:$PATH'e tutto ha iniziato a funzionare correttamente.

Ho usato gedit per aggiornare il PATH in modo permanente, dopo essermi assicurato che non avrebbe rotto i miei normali toolchain.

Spiegazione:

Ho più toolchain installati su Ubuntu 14.04LTS e ne uso solo un paio regolarmente. Quando ho provato a utilizzare gcc dalla riga di comando, ho ricevuto il problema descritto dall'OP. '/ usr / bin' si trova nel PERCORSO ma è dietro le altre posizioni della toolchain. Si scopre che il cc1 per gli altri toolchain non è compatibile con gcc.

Solo per completare la risposta di @maxkoryukov riguardo ad Alpine.

L'equivalente di Debian build-essentialin Alpine è build-base. In effetti, quanto sopra alpine-sdkdipende da 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

Puoi risolverlo eseguendo questo: Su Fedora:

sudo dnf install redhat-rpm-config

Ho riscontrato questo problema su un'installazione ragionevolmente nuova di Fedora 27. Ho provato tutti gli altri suggerimenti o i loro equivalenti; l'installazione dei vari pacchetti diceva "già installato" o installava qualcosa di nuovo che non aiutava.

Risolto con

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

Su Scientific Linux 6 (simile a CentOS 6-- SL è ora sostituito da CentOS, AIUI), ho dovuto usare quello /usr/sbin/prelink -av -mRche ho trovato suggerito su https://stelfox.net/blog/2014/08/dependency-prelink-issues/

Fino a quando non l'ho fatto, ho ricevuto un errore cc1 gcc: error trying to exec 'cc1': execvp: No such file or directoryquando ho provato a compilare e gcc --version riportava 4.2.2 invece di 4.4.7, nonostante quella versione fosse segnalata da yum.

Potrebbe essere correlato o meno, ma il sistema aveva esaurito lo spazio su / var

È in questo pacchetto (Ubuntu 19.04):

  sudo apt install g++-6

Nel mio raro caso è stato color wrapperchi ha rovinato gcc. Risolto disabilitando l' cwesclusione della sua directory /usr/libexec/cwdalla PATHvariabile ambientale.

Perché succede questo? Quando installi una nuova copia di Linux, il compilatore gcc viene fornito preconfezionato. Contiene solo i file e i binari usati per eseguire Linux (per risparmiare spazio e tempo, ovviamente).

Come risolvere questo errore? Tutto ciò di cui hai bisogno è aggiornare i tuoi pacchetti tramite il gestore pacchetti e reinstallare i pacchetti essenziali per la compilazione. I comandi potrebbero essere diversi su diversi kernel.