it-swarm.com.de

CreateProcess: Keine solche Datei oder Verzeichnis

Diese Fehlermeldung wird jedes Mal angezeigt, wenn ich versuche, GCC außerhalb des Installationsverzeichnisses (E:\MinGW\bin) auszuführen. 

Nehmen wir also an, ich bin in E:\code und habe eine Datei namens one.c. Wenn Sie: gcc one.c -o one.exe ausführen, wird mir diese Fehlermeldung angezeigt:

gcc: CreateProcess: No such file or directory

Die einzige Problemumgehung besteht darin, zum Installationsverzeichnis zu navigieren, gcc von dort aus auszuführen und alle anderen Pfade anzugeben. Meine Umgebungsvariable Path enthält E:\MinGW\bin.

Anregungen zur Behebung dieses Problems? Ich verwende Windows XP SP3.

42
Insomaniacal

Es wurde ausdrücklich gesagt, dass Sie einen Neustart durchführen müssen, nachdem Sie die Umgebungsvariablen in Windows für migwin festgelegt haben. 

2
user235273

Gemäß Code :: Blocks wiki müssen Sie C:\MinGW\libexec\gcc\mingw32\MinGW-Version zu Ihrer PATH hinzufügen. Es ist kein Neustart erforderlich, aber Sie müssen ein anderes Terminal öffnen, um die neuesten PATH-Einstellungen zu erhalten.

Für MinGW-w64 ist das <mingw install directory>\libexec\gcc\x86_64-w64-mingw32\4.7.0\

29
Herberth Amaral

Ich hatte ein ähnliches Problem, weil der C++ - Compiler nicht installiert wurde. In meinem Fall kompilierte ich .cpp-Dateien für eine Python-Erweiterung, aber der Compiler wird zuerst als c:\mingw\bin\gcc.exe aufgerufen.

Intern würde gcc.exe feststellen, dass es aufgefordert wurde, eine .cpp-Datei zu kompilieren. Es würde versuchen, g ++. Exe aufzurufen, und die gleiche Fehlermeldung würde fehlschlagen:

gcc.exe: CreateProcess: Keine solche Datei oder Verzeichnis

29
Luis Bruno

Ich hatte gerade dieses Problem.

In meinem Fall war das Problem auf Probleme beim Herunterladen der Pakete für GCC zurückzuführen. Das mingw-get-Programm meinte, der Download sei abgeschlossen, aber nicht der Fall.

Ich wollte GCC aktualisieren, also habe ich mingw-get verwendet, um die neuere Version zu erhalten. Aus irgendeinem Grund dachte mingw-get, der Download einer bestimmten Datei sei abgeschlossen, aber nicht der Fall. Wenn ich die Datei extrahieren wollte, gab es vermutlich einen Fehler (was ich nicht einmal bemüht habe, nachzusehen - ich habe einfach "mingw-get update && mingw-get install mingw32-gcc" ausgeführt und dort belassen).

Um das Problem zu lösen, entfernte ich gcc mit "mingw-get remove mingw32-gcc" und entfernte auch die Paketdatei (die Datei, die mingw-get nicht vollständig heruntergeladen hat), die sich im mingw-Cache-Ordner ("C:\MinGW\var\cache\mingw-get\packages "in meinem System) und führte dann den Installationsbefehl erneut aus. Die fehlenden Teile von GCC wurden heruntergeladen und installiert (das Paket gcc-core wurde nicht vollständig heruntergeladen).

Das hat mein Problem gelöst.

Interessanterweise war mingw-get intelligent genug, um den Download von gcc-core auch dann fortzusetzen, nachdem ich die Paketdatei im Cache-Ordner gelöscht und das Paket mingw32-gcc entfernt hatte.

Ich denke, das grundlegendere Problem war, dass cc1 nicht vorhanden war, da keine gcc-core-Dateien installiert waren. Und gcc verwendet cc1. Ich glaube, als gcc versucht hat, cc1 zu starten, hat CreateProcess irgendwo den Pfad von cc1 verwendet, der nicht der Pfad einer vorhandenen Datei war. Also die Fehlermeldung.

Das ist also eine dumme Fehlermeldung, weil sie welche -Datei nicht findet.

Führen Sie den Befehl erneut mit dem ausführlichen Flag gcc -v aus, um zu sehen, was gcc vorhat.

In meinem Fall war es der Fall, dass versucht wurde, cc1plus aufzurufen. Ich habe nachgesehen, das habe ich nicht. Installierte den C++ - Compiler von mingw und dann tat ich es.

6
Colonel Panic

Ich hatte genau das gleiche Problem. 

Nach einer Überprüfung meiner PATH wurde mir klar, dass ich sowohl Mingw (64 Bit) als auch Cygwin (32 Bit) installierte. Das Problem ist, dass sowohl Mingw als auch Cygwing++ haben. 

Durch Deaktivieren des Pfads von Cygwin ist der Fehler verschwunden. 

5
znatz

Beim Versuch, von Cygwin mit Links zur mingw-Installation zu laufen, wurde dieselbe Fehlermeldung angezeigt.

Verwenden Sie dieselbe Installation von mingw32-make-3.80.0-3.exe aus http://www.mingw.org/wiki/FAQ und die Option mingw Shell über Start -> Programme -> auf einem WinXP SP3 und gcc funktioniert gut.

2
iulian

Ich habe ein ähnliches Problem erfahren. Durch das Hinzufügen des Ordners GCC bin zu meinem Systempfad konnte das Problem zunächst nicht behoben werden. Ich habe zwei Lösungen gefunden.

Die erste bestand darin, eine Batchdatei auszuführen, die ich im Stammverzeichnis der MinGW-Installation, mingwbuilds.bat, gefunden habe. Es startet (anscheinend) eine Eingabeaufforderung, die ordnungsgemäß für die Ausführung von GCC konfiguriert ist. Die zweite bestand darin, doppelte Anführungszeichen aus dem GCC-Installationsordner zu entfernen, den ich meiner Benutzerpfadvariablen hinzugefügt hatte. Ich habe dies versucht, nachdem ich bemerkt hatte, dass die Batchdatei keine doppelten Anführungszeichen um den Installationspfad gab.

Zusätzliche Details

Ich habe die Batchdatei beim Durchsuchen des Installationsordnerbaums aus Versehen gefunden und versucht, die verschiedenen ausführbaren Dateien zu finden, die nicht gestartet wurden (entsprechend der Ausgabe von -v). Ich habe im MinGW-Wiki ( http://www.mingw.org/wiki/Getting_Started ) einige Informationen in den Abschnitten "Vorsichtsmaßnahmen und Umgebungseinstellungen" gefunden, die angeben, warum das MinGW-Installationsprogramm das System oder den Benutzerpfad nicht einrichtet um den Installationsordner einzuschließen. Diese scheinen zu bestätigen, dass die Batchdatei dazu gedacht ist, eine Eingabeaufforderung zu starten, die für die Ausführung von GCC über eine Windows-Eingabeaufforderung geeignet ist.

1
Dave Richardson

Ich hatte das gleiche Problem und keine der vorgeschlagenen Korrekturen funktionierte für mich. Auch wenn dies ein alter Thread ist, denke ich, dass ich meine Lösung auch posten könnte, falls jemand diesen Thread durch Google findet (wie ich es tat).

Für mich musste ich MinGW deinstallieren/den MinGW-Ordner löschen und neu installieren. Nach der Neuinstallation funktioniert es wie ein Zauber.

1
Lyle

Dieses Problem tritt auf, weil Sie Großbuchstaben-Suffix stuff.C und nicht Kleinbuchstaben stuff.c verwenden, wenn Sie es mit Mingw GCC kompilieren. Zum Beispiel, wenn Sie das mögen: 

gcc -o stuff stuff.C

dann erhalten Sie die Nachricht: gcc: CreateProcess: No such file or directory

Aber wenn du das tust:

 gcc -o stuff stuff.c

dann klappt es. Ich weiß nur nicht warum.

1
tess

Ich hatte das gleiche Problem, aber keine der derzeit aufgelisteten Lösungen half beim ersten Versuch.

Die -v-Option gab keine zusätzlichen Hinweise.

Musste auf ProcMon zurückgreifen, um die Wurzel des Problems finden zu können.

Beim Ablegen der g++-Prozessdatei-Aktivität wurden zahlreiche Versuche gefunden, cc1plus-Programmdatei auf verschiedenen Pfaden zu finden. Unter ihnen gab es Wege zur alten GCC-Version.

Diese alte Version befand sich jedoch in einem separaten Ordner und wurde von der neuen Version, auf die ich versuchte, ausgeführt, überhaupt nicht referenziert.

Zuletzt wurde der veraltete Pfad in der Umgebungsvariablen ..% des Systems% PATH% gefunden. Nach dem Entfernen funktionierte die neue Version fehlerfrei.

1
Vadzim

Ich hatte einen sehr langen Pfad, und da ist irgendwo eine Datei (nicht gcc.exe), sondern eine andere Datei, auf die gcc.exe vom Pfad aus zugreift.

Wenn ich also den Weg frei gemacht habe, hat es funktioniert

C:\MinGW>cd bin


C:\MinGW\bin>where gcc.exe
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe

^^ Wenn Sie also gcc von dort ausführen, wird auf jeden Fall die ming gcc.exe ausgeführt

C:\MinGW\bin>type file6.c
#include<stdio.h>
void main()
{
int num1,num2;
scanf("%2d %4d",&num1,&num2);
printf("a=%d b=%d",num1,num2);
scanf("%d",&num1);
//flushall();
printf("c=%d",num1);
}

Beim Kompilieren bekam ich diesen Fehler

C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory

Mein PFAD war riesig

C:\MinGW\bin>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\system32\wbem;C:\P......

C:\MinGW\bin> Pfad | grep -io "ming"

Es hat sich dort nicht vermischt. 

C:\MinGW\bin> Echo MING | grep -io "ming" MING

(und ja, dass grep funktioniert ... der Pfad hat sich dort nicht vermischt)

Den Weg frei zu machen, hat mich zur Arbeit gebracht!

C:\MinGW\bin>set PATH=

C:\MinGW\bin>gcc file6.c

C:\MinGW\bin>

Es ist also noch nicht klar, was genau im PATH zu dem Zusammenstoß geführt hat. Welches Verzeichnis, welche Datei.

Update-

Das obige scheint mir richtig zu sein, aber es ist auch kein einfacher Fall, wenn etwas früher im Pfad kollidiert. Normalerweise hat das aktuelle Verzeichnis Vorrang. Und hier ist es soweit, wie gcc --version zeigt, dass es das Ming eins ausführt und nicht eines in einem Konfliktverzeichnis. Es ist also etwas komisch, wenn sich das Verzeichnis mit den Konflikten im Pfad befindet, müssen Sie entweder.\Gcc oder . am Anfang des Pfads oder c:\MinGW\bin vor in Konflikt stehenden Verzeichnissen im Pfad hinzufügen. Dies ist auch dann der Fall, wenn Sie sich in C:\MinGW\bin befinden und das ist merkwürdig. Und wenn es einen Fehler gibt, wird immer noch Mings gcc ausgeführt, aber (aus irgendeinem Grund) wird auch das in Konflikt stehende Verzeichnis betrachtet, wie ich es vom Prozessmonitor sehe. Möglicherweise finden Sie hier mehr Antworten http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista in dem Link, der in der hier oben erwähnten Antwort erwähnt wird 

Das ist Ming32-Bit ..

Wenn man sich Ming 64bit anschaut, hat es wahrscheinlich das selbe Problem, aber ich sehe interessanterweise eine Bat-Datei, die das Verzeichnis bin (sinnvoll) an den Pfad des Pfads setzt. Und es sieht so aus, als wäre dies eine Standardmethode, um Ming gcc richtig auszuführen. 

Der code :: blocks IDE (sinnvoll) setzt das bin-Verzeichnis ebenfalls am Anfang des Pfads. Wenn Sie ein C-Programm ausführen, das Umgebungsvariablen anzeigt, sehen Sie das.

1
barlop

In der "Gib einem Mann einen Fisch, füttere ihn für einen Tag; lehre einen Mann das Fischen, mach ihn für das ganze Wochenende los" 

g ++ --help
zeigt Compiler-Optionen. Die Option g ++ -v hilft:

   -v Zeigt die vom Compiler aufgerufenen Programme an

Durchsuchen Sie die Ausgabe nach falschen Pfaden. In meinem Fall der ursprüngliche Befehl:

g ++ -v "d: /UW_Work/EasyUnit/examples/1-BasicUnitTesting/main.cpp"

erzeugte Ausgabe einschließlich dieses kleinen Edelsteins:

-iprefix c:\olimexods\yagarto\arm-none-eabi\bin\../ lib/gcc/arm-none-eabi/4.5.1 /

was die Meldung "Keine solche Datei oder Verzeichnis" erklären würde. 

Das Segment "../lib/gcc/arm-none-eabi/4.5.1/" stammt von den integrierten Spezifikationen:

g ++ - Dumpspecs
1
Technophile

Dieses Problem kann auftreten, wenn Sie verschiedene Programmversionen haben.

Beispielsweise haben Sie ein Jahr gcc und möchten einen C++ - Quellcode kompilieren. Wenn Sie mingw-get zur Installation von g++ verwenden, werden gcc und g++ plötzlich unterschiedliche Versionen haben und Sie könnten sich in dieser Situation befinden.

Das Ausführen von mingw-get update und mingw-get upgrade hat dieses Problem für mich gelöst.

0
bubla

Fügen Sie E:\MinGW\bin zur Variable PATH hinzu.

0
ruslik

Obwohl Post älter ist, hatte ich am 13.02.2015 das gleiche Problem mit mingw32 vers 4.8.1. Das Kompilieren mit Eclipse CDT ist mit dieser Nachricht fehlgeschlagen. Der Versuch über die Befehlszeile mit der Option -v ist ebenfalls fehlgeschlagen. Ich habe auch die ausführbare Datei cc1plus vermisst.

Ursache: Ich habe die Befehlszeile und das grafische Installationsprogramm von der mingw32-Site heruntergeladen. Ich habe dies zur ersten Installation von mingw32 verwendet. Mit der GUI habe ich die Basis-Tools ausgewählt und sowohl den C- als auch den C++ - Compiler ausgewählt.

Dieses Installationsprogramm hat den 32-Bit-C++ - Compiler nicht vollständig installiert. Ich hatte die g ++ - und cpp-Dateien, aber nicht die ausführbare Datei cc1plus. Der Versuch, ein "Update" durchzuführen, ist fehlgeschlagen, weil das Installationsprogramm davon ausgegangen ist, dass alles installiert wurde.

Zur Behebung habe ich folgende Sites gefunden: http://mingw-w64.sourceforge.net/http://sourceforge.net/projects/mingw-w64/ Ich habe diese "Online-Installation" heruntergeladen und ausgeführt. Sicher, diese enthielt die fehlenden Dateien. Ich änderte meine PATH-Variable und zeigte auf den Ordner "bin", der die ausführbare g ++ - Datei enthält. Neustart Installierte 64-Bit-Eclipse. Eclipse wurde geöffnet und das C++ - Programm 'Hello World' wurde ordnungsgemäß kompiliert, ausgeführt und debuggt.

Hinweis: Das 64-Bit-Installationsprogramm scheint die UNIX-Einstellungen standardmäßig zu verwenden. Warum kann ein Installer das Betriebssystem nicht bestimmen? Stellen Sie sicher, dass Sie sie ändern.

Ich verbrachte einen ganzen Abend damit, mich damit zu beschäftigen. Hoffe das hilft jemandem.

0
user4567472

Ich hatte das gleiche Problem. 

Ich hatte bereits einen g ++ - Compiler durch MinGW installiert (das Paket mingw32-gcc-g ++ ), aber ich brauchte einen C-Compiler. Ich ließ mingw-get-setup.exe laufen, wo ich die mingw32 installieren konnte -base package, das mit dem C-Compiler. 

Ach! Ich hatte diesen Fehler, wenn ich mit gcc kompiliere:

gcc: error: createprocess: keine solche Datei oder Verzeichnis

Was ich tat, war, immer noch mit dem MinGW-Installations-Manager, entfernte ich die C- und C++ - Compiler-Pakete, nämlich mingw32-base und mingw32-gcc-g ++ und ALSO löschte das Verzeichnis C:\MinGW selbst. Dann habe ich mingw-get-setup.exe reran, installiert mingw32-base und voila, es hat funktioniert :) 

0
PFrancisco

Ich hatte das gleiche Problem (ich laufe cygwin)

Das Starten einer Shell über cygwin.bat hat nicht geholfen, das Starten einer Shell über MingWShell jedoch. Nicht ganz sicher warum, aber ich denke, es hatte etwas mit der zusätzlichen Schicht zu tun, die cygwin zwischen dem ausführenden Skript und dem zugrunde liegenden Dateisystem legt.

Ich habe eine Pip-Installation von einem virtuellen Env-Cygwin aus ausgeführt, um den Django-Wachposten zu installieren.

0
Taras

Es sieht so aus, als gäbe es ein paar Veröffentlichungen für MinGW. Welches hast du probiert? Für das Protokoll habe ich genau das gleiche Problem wie das OP und die Distribution, die ich bekam, von TDM-GCC 4.5.1.

Ich fand die MinGW-Distribution hier scheint viel besser zu funktionieren und stellt die Dinge richtig ein. Wenn Sie also auf diesen verzögerten Fehler "createprocess-no-such-file-or-directory" stoßen, der die Dinge nicht zum Laufen bringen kann, deinstallieren Sie Ihr vorhandenes MinGW und versuchen Sie stattdessen den Link, den ich verlinkt habe.

0
greatwolf

Ich hatte das gleiche Problem und versuchte alles ohne Ergebnis. Was das Problem gelöst hat, war die Reihenfolge der Bibliothekspfade in der PATH-Variablen zu ändern. Ich hatte Cygwin sowie einige andere Compiler, also gab es wahrscheinlich eine Art Kollision zwischen ihnen. Was ich tat, war das C:\MinGW\bin; Pfad zuerst vor allen anderen Pfaden und es hat das Problem für mich behoben!

0
Ioannis

(Bezieht sich auf das ursprüngliche Problem) 
Die heutige Version von mingw (siehe Postdatum) 
Alles, was ich tun musste, war, den Pfad in derselben Shell festzulegen, die ich gcc lief.
Ich brauchte eine Stunde, um mich daran zu erinnern, wie man DOS variables...

A:> set PATH=C:\MinGW\bin\;
C:\Program Files\ImageMagick-6.8.0-Q16\;
C:\WINDOWS\system32\;C:\WINDOWS\;C:\WINDOWS\System32\Wbem\;
C:\WINDOWS\system32\WindowsPowerShell\v1.0\;
C:\Program Files\QuickTime\QTSystem\
A:> gcc hi.c
0
David Lambert

versuchen Sie, den Pfad in die Systemvariablen einzufügen, anstatt Benutzervariablen in Umgebungsvariablen einzutragen.

0
saimadan

Ich habe diese Fehlermeldung erhalten, weil ich MinGW-w64 verwendete und die Befehle in <install path>\bin alle ein seltsames Präfix hatten. Ich habe versucht, ausführbare Dateien in den "Zielalias" -Verzeichnissen anstelle in <install path>\bin-Verzeichnissen aufzurufen, was zu noch mehr Problemen führte. Das ist ein Nein nach dem FAQ . Für mich bestand die Lösung darin, symbolische Links zu allen vorangestellten Befehlen zu erstellen. Ich öffnete eine Eingabeaufforderung mit erhöhtem Befehl und verwendete etwas wie mklink gcc.exe x86_64-w64-mingw32-gcc.exe für jede ausführbare Datei. Jetzt funktioniert mein Build.

0
Ben