Gcc-Fehler: gcc: Fehler beim Ausführen von 'cc1': execvp: Keine solche Datei oder Verzeichnis

Unter debian/ubuntu habe ich dieses Problem durch die Neuinstallation von build-essential behoben:

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

Auf CentOS oder Fedora

yum install gcc-c++ 

Dies liegt daran, dass gcc viele andere ausführbare Dateien aufruft, um die Verarbeitung der Eingabe abzuschließen, und cc1 nicht im eingeschlossenen Pfad enthalten ist.

Auf der Shell geben Sie whereis cc1 ein. Wenn cc1 gefunden wird, ist es besser, einen Softlink im Verzeichnis von gcc zu erstellen. Andernfalls ist cc1 nicht installiert, und Sie müssen gcc-c ++ mithilfe des Paketmanagers installieren.

1. Erklärung

In der Fehlermeldung wurde Ihnen mitgeteilt, dass die Build-Time-Abhängigkeit nicht gefunden wurde. Sie müssen also nur das entsprechende Paket auf Ihrem System installieren (mithilfe des Paket-Managers, aus Quellen erstellen oder auf andere Weise).

Was ist cc1:

cc1 ist der interne Befehl, der vorverarbeitete C-Sprachdateien in Assembly konvertiert. Es ist der eigentliche Teil, der C kompiliert. Für C++ gibt es cc1plus und andere interne Befehle für verschiedene Sprachen.

^{aus dieser Antwort entnommen von Alan Shutko .}

2. Lösungen

Ubuntu/Linux Mint

Sudo apt-get install --reinstall build-essential

Docker-alpine Umgebung

Wenn Sie sich in der Umgebung von docker-Alpine befinden, installieren Sie den build-base , indem Sie Folgendes hinzufügen:

RUN apk add build-base

zu Ihrer Dockerfile. Wenn Sie mehr Pakete für den Bau benötigen, sollten Sie das Paket Alpine-sdk hinzufügen.

Aus github

Ich bin heute auf ein ähnliches Problem gestoßen - ein Mitarbeiter konnte seine Software nicht erstellen, aber ich konnte sie erstellen. Als er gcc lief, konnte er cc1 nicht finden.

Sein ausführbarer Pfad sah vernünftig aus, aber die Tatsache, dass ich den Fehler nicht ohne weiteres replizieren konnte, ließ auf etwas in seiner Umgebung schließen.

Schließlich fanden wir GCC_EXEC_PREFIX in seiner Umgebung definiert, was der Täter war und gcc bei der Suche nach cc1 irreführend war. Dies war Teil seiner Shell-Startskripts und sollte eine Einschränkung für ein nicht mehr verwendetes SPARC/Solaris-System umgehen. Das Problem wurde gelöst, indem diese Umgebungsvariable nicht gesetzt wurde.

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

Amazon Linux: Behebung des GCC-Problems

Da dies das erste Ergebnis bei Google ist, wollte ich nur meine Erfahrungen mit Amazon Linux dokumentieren. Durch die Installation von gcc-c++.noarch wurde das Problem behoben:

Sudo yum install gcc-c++.noarch

Einige Leute berichteten auch von dieser Alternative als Lösung:

Sudo yum install gcc72-c++

Ich habe dieses Problem behoben, indem ich explizit g ++ installierte:

Sudo apt-get install g++

Bei der Installation von Pandas ist auf Ubuntu 12.04 ein Problem aufgetreten. (Danke Gefahrkraut.)

yum install gcc-c++ hat das Problem behoben.

Stellen Sie sicher, dass Ihre GCC_EXEC_PREFIX(env) nicht exportiert wird und Ihre PATH in die rechte Werkzeugkette exportiert wird.

Nur um meine Probleme mit diesem Problem zu dokumentieren, obwohl es nur ein konkretes Beispiel für andere Antworten zu sein scheint; Als relativer Neuling denke ich, dass dies anderen helfen könnte. 

Lösung:

Mit PATH='/usr/path/:$PATH' fügte ich am Anfang von PATH '/ usr/bin' hinzu und alles begann gut zu funktionieren. 

Ich habe gedit verwendet, um den PATH dauerhaft zu aktualisieren, nachdem sichergestellt wurde, dass er meine normalen Toolchains nicht beschädigt.

Erläuterung:

Ich habe mehrere Toolchains auf Ubuntu 14.04LTS installiert und verwende regelmäßig nur ein paar. Als ich versuchte, gcc von der Kommandozeile aus zu verwenden, wurde mir das Problem vom OP beschrieben. '/ usr/bin' befindet sich im PATH, aber hinter den anderen Toolchain-Positionen. Stellt sich heraus, dass cc1 für diese anderen Toolchains nicht mit gcc kompatibel ist.

Was mir dabei geholfen hat, war llvm-gcc statt

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

Ich habe dies kurz nach der Kompilierung und Installation einer glänzenden neuen GCC - Version 8.1 - auf RHEL 7 erlebt. Am Ende war dies ein Berechtigungsproblem. Mein Stamm umask war der Schuldige. Ich fand schließlich cc1 in /usr/local/libexec versteckt:

[[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

Die Berechtigungen für die dortigen Verzeichnisse erlaubten jedoch nicht meinem Standardbenutzerkonto:

[[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

Eine schnelle rekursive chmod zum Hinzufügen von Lese-/Ausführungsberechtigungen für die Welt behebte das Problem:

[[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

Und jetzt kann gcccc1 finden, wenn ich etwas zum Kompilieren frage!

Dies kann auch die angezeigte Fehlermeldung sein, wenn Sie versuchen, 32-Bit-gcc-Binärdateien unter einem 64-Bit-Betriebssystem auszuführen und 32-Bit-Glibc zu fehlen. Entsprechend dieser readme : "Für 64-Bit-Systeme sind 32-Bit-Programme libc und libncurses erforderlich, um die Tools auszuführen." . In diesem Fall gibt es kein Problem mit dem Pfad und cc1 wird tatsächlich gefunden, aber als fehlend gemeldet als keine 32-Bit-Glibc.

Unter Scientific Linux 6 (ähnlich wie CentOS 6 - SL wird jetzt durch CentOS, AIUI ersetzt) ​​musste ich /usr/sbin/prelink -av -mR verwenden, den ich unter https://stelfox.net/blog/2014/08/dependency-prelink vorgeschlagen fand -Probleme/

Bis ich das tat, bekam ich einen cc1-Fehler gcc: error trying to exec 'cc1': execvp: No such file or directory, als ich versuchte zu kompilieren, und gcc --version meldete 4.2.2 anstatt 4.4.7, obwohl diese Version von yum gemeldet wurde.

Es kann sein, dass ein Zusammenhang besteht, aber das System hat auf/var nicht genügend Speicherplatz

Nur um die Antwort von @ maxkoryukov zu Alpine zu ergänzen.

Das Äquivalent zu Debians build-essential in Alpine ist build-base. Tatsächlich hängt der oben erwähnte Alpine-sdk von build-base ab.

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

Sie können dies beheben, indem Sie Folgendes ausführen: Bei Fedora:

Sudo dnf install redhat-rpm-config

Es ist in diesem Paket (Ubuntu 19.04): 

  Sudo apt install g++-6

Ich habe dieses Problem bei einer relativ neuen Installation von Fedora 27 erlebt. Ich habe alle anderen Vorschläge oder deren Entsprechungen ausprobiert. Die Installation der verschiedenen Pakete sagte entweder "bereits installiert" oder installierte etwas Neues, was nicht half.

Fixiert mit

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