CreateProcess: Aucun fichier ou répertoire de ce type
Je reçois cette erreur chaque fois que j'essaie d'exécuter GCC en dehors de son répertoire d'installation (E:\MinGW\bin).
Donc, disons que je suis dans E:\code et que j'ai un fichier appelé one.c. En cours d’exécution: gcc one.c -o one.exe me donnera cette erreur:
gcc: CreateProcess: No such file or directory
La seule solution consiste à accéder à son répertoire d'installation, à exécuter gcc à partir de cet emplacement et à spécifier tous les autres chemins. Ma variable d'environnement Path contient E:\MinGW\bin.
Des suggestions pour résoudre ce problème? J'utilise Windows XP SP3.
Son spécifiquement dit que vous devez redémarrer après avoir défini les variables d'environnement dans Windows pour migwin.
Selon Code :: Blocks wiki , vous devez ajouter C:\MinGW\libexec\gcc\mingw32\MinGW-Version à votre PATH. Il n'est pas nécessaire de redémarrer l'ordinateur, mais vous devez ouvrir un autre terminal pour obtenir les derniers paramètres PATH.
Pour MinGW-w64, il s'agit de <mingw install directory>\libexec\gcc\x86_64-w64-mingw32\4.7.0\
J'ai eu un problème similaire, causé par ne pas installer le compilateur C++. Dans mon cas, je compilais des fichiers .cpp pour une extension Python, mais le compilateur est d'abord appelé en tant que c:\mingw\bin\gcc.exe.
En interne, gcc.exe remarquerait qu'il lui a été demandé de compiler un fichier .cpp. Il essaierait d'appeler g ++. Exe et échouerait avec le même message d'erreur:
gcc.exe: CreateProcess: aucun fichier ni répertoire de ce type
Je viens d'avoir ce problème.
Dans mon cas, le problème était dû à des problèmes lors du téléchargement des packages pour GCC. Le programme mingw-get a pensé qu'il avait terminé le téléchargement, mais il ne l'a pas fait.
Je voulais mettre à jour GCC, alors j’ai utilisé mingw-get pour obtenir la version la plus récente. Pour une raison quelconque, mingw-get pensait que le téléchargement d'un fichier particulier était terminé, mais ce ne l'était pas. Quand il est allé extraire le fichier, je suppose qu'il a émis une erreur (que je n'ai même pas pris la peine de regarder - je viens d'exécuter "mingw-get update && mingw-get install mingw32-gcc" et de le laisser là).
Pour résoudre ce problème, j’ai supprimé gcc en faisant «mingw-get remove mingw32-gcc» et également supprimé le fichier de package (celui que mingw-get n’a pas entièrement téléchargé), qui se trouvait dans le dossier de cache mingw ("C:\MinGW\var\cache\mingw-get\packages "dans mon système), puis réexécutez la commande install. Il a téléchargé et installé les parties manquantes de GCC (le package gcc-core n’avait pas été entièrement téléchargé).
Cela a résolu mon problème.
Il est intéressant de noter que mingw-get était assez intelligent pour continuer le téléchargement de gcc-core, même après avoir supprimé le fichier de package dans le dossier de cache, ainsi que le package mingw32-gcc.
Je pense que le problème le plus fondamental était que, puisque les fichiers gcc-core n’étaient pas installés, cc1 n’y était pas. Et gcc utilise cc1. Je suppose que lorsque gcc a essayé de démarrer cc1, il a utilisé CreateProcess quelque part en passant par le chemin de cc1, qui n’était pas le chemin d’un fichier existant. Ainsi, le message d'erreur.
C'est donc un message d'erreur stupide car il ne vous dit pas ce que fichier qu'il ne peut pas trouver.
Exécutez à nouveau la commande avec l'indicateur détaillé gcc -v pour voir ce que gcc prépare.
Dans mon cas, il est arrivé qu'il essayait d'appeler cc1plus. J'ai vérifié, je n'ai pas ça. J'ai installé le compilateur C++ de mingw, puis je l'ai fait.
J'ai eu exactement le même problème.
Après avoir revérifié ma PATH, j’ai réalisé que j’avais installé Mingw (64 bits) et Cygwin (32 bits). Le problème est que Mingw et Cygwin ont g++.
En désactivant le chemin de Cygwin, l'erreur a disparu.
Le même message d'erreur apparaissait lorsque j'essayais de lancer Cygwin avec des liens vers l'installation mingw.
Utilisation de la même installation de mingw32-make-3.80.0-3.exe à partir de http://www.mingw.org/wiki/FAQ et de l’option mingw Shell à partir de Démarrer -> Programmes -> sur un WinXP SP3 et gcc fonctionne bien.
J'ai eu un problème similaire. Initialement, l'ajout du dossier bin GCC à mon chemin d'accès système ne résolvait pas le problème. J'ai trouvé deux solutions.
La première consistait à exécuter un fichier de commandes que j'ai trouvé à la racine de l'installation de MinGW, mingwbuilds.bat. Il lance (apparemment) une invite de commande configurée correctement pour exécuter GCC. La seconde consistait à supprimer les guillemets doubles du dossier bin d'installation de GCC que j'avais ajouté à la variable de chemin d'accès de l'utilisateur. J'ai essayé ceci après avoir remarqué que le fichier de commandes n'utilisait pas de guillemets doubles autour du chemin d'installation.
Détails supplémentaires
J'ai trouvé le fichier de commandes par inadvertance lors de la navigation dans l'arborescence du dossier d'installation en essayant de localiser les différents exécutables qui ne se lancaient pas (d'après la sortie -v). J'ai trouvé des informations sur le wiki MinGW, http://www.mingw.org/wiki/Getting_Started , dans les sections Précautions et Paramètres d'environnement, qui indiquent pourquoi le programme d'installation de MinGW ne configure pas le chemin d'accès système ou utilisateur inclure le dossier d'installation. Celles-ci semblent confirmer que le fichier de commandes est destiné à lancer une invite de commande adaptée à l'exécution de GCC à partir d'une invite Windows.
J'ai eu le même problème et aucune des solutions suggérées ne fonctionnait pour moi. Donc, même s’il s’agit d’un ancien fil de discussion, j’imagine que je pourrais aussi bien publier ma solution au cas où une autre personne trouve ce fil via Google (comme je l’ai fait).
Pour moi, je devais désinstaller MinGW/supprimer le dossier MinGW, puis le réinstaller. Après la réinstallation, cela fonctionne à merveille.
Ce problème est dû au fait que vous utilisez suffixe majuscule stuff.C plutôt que minuscule stuff.c lorsque vous le compilez avec Mingw GCC. Par exemple, quand vous faites comme ceci:
gcc -o stuff stuff.C
alors vous obtiendrez le message: gcc: CreateProcess: No such file or directory
Mais si vous faites ceci:
gcc -o stuff stuff.c
alors ça marche. Je ne sais juste pas pourquoi.
J'ai eu le même problème, mais aucune des solutions répertoriées actuellement n'a aidé au premier essai.
L'option -v n'a donné aucun indice supplémentaire.
J'ai dû recourir à ProcMon pour pouvoir trouver la racine du problème.
Le vidage de l'activité du fichier de processus g++ a révélé de nombreuses tentatives pour trouver l'exécutable cc1plus dans différents chemins. Il y avait des chemins vers l'ancienne version de GCC parmi eux.
Mais cette ancienne version résidait dans un dossier séparé et n'était pas du tout référencée depuis la nouvelle version que j'ai essayé de lancer.
Enfin, le chemin obsolète a été trouvé dans la variable d’environnement système% PATH% . Après l’avoir supprimée, la nouvelle version a commencé à fonctionner sans erreur.
J'ai eu un très long chemin, et il y a un fichier quelque part (pas gcc.exe) mais un autre fichier, auquel gcc.exe accède depuis le chemin ..
Donc, quand j'ai dégagé le chemin, cela a fonctionné
C:\MinGW>cd bin
C:\MinGW\bin>where gcc.exe
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe
^^ Donc, lancer gcc à partir de là exécutera certainement le ming gcc.exe
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);
}
En le compilant j'ai eu cette erreur
C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory
Mon chemin était énorme
C:\MinGW\bin>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\system32\wbem;C:\P......
C:\MinGW\bin> chemin | grep -io "ming"
Il n'y avait pas ming là.
C:\MinGW\bin> echo MING | grep -io "ming" MING
(Et oui, ça marche. Le chemin n'était pas là.)
Dégager complètement mon chemin, l'a conduit au travail!
C:\MinGW\bin>set PATH=
C:\MinGW\bin>gcc file6.c
C:\MinGW\bin>
Donc, on ne sait pas encore avec précision ce que c'était dans le PATH qui a conduit à l'affrontement. Quel répertoire, quel fichier.
Mettre à jour-
Ce qui précède me semble correct, mais je tiens à ajouter qu’il ne s’agit pas non plus d’un cas simple de quelque chose de plus tôt dans le conflit de chemins .. car normalement le répertoire en cours est prioritaire. Et c’est le cas ici dans la mesure où gcc --version montre qu’il exécute le ming et non l’un des répertoires en conflit. Il y a donc quelque chose de drôle à ce sujet, si le répertoire en conflit est dans le chemin), il faut soit faire\gcc, soit ajouter . au début du chemin, soit ajouter c:\MinGW\bin avant tout répertoire en conflit dans le chemin. c'est le cas même lorsque vous êtes dans C:\MinGW\bin et c'est étrange. Et quand il donne une erreur, il continue à utiliser le gcc de Ming mais (pour une raison quelconque) aussi à regarder le répertoire en conflit, comme je le vois à partir du moniteur de processus. Vous trouverez peut-être plus de réponses ici http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista dans le lien mentionné dans la réponse très votée ici
C'est Ming32 bit ..
En regardant Ming 64 bits, le problème est probablement le même, mais je vois qu’il est intéressant de noter qu’il est livré avec un fichier chauve-souris qui (à bon escient) place réellement le répertoire bin à la racine du chemin. Et il semble que ce soit une manière standard d’exécuter correctement Ming gcc.
Le code :: blocks IDE (judicieusement) place également le répertoire bin au début du chemin. Si vous exécutez un programme C qui affiche les variables d’environnement, vous le voyez.
Dans "Donnez à un homme un poisson, donnez-lui à manger pendant une journée; apprenez à un homme à pêcher, débarrassez-vous de lui pendant tout le week-end",
g ++ --helpaffiche les options du compilateur. L'option g ++ -v aide à:
-v Affiche les programmes appelés par le compilateur
Regardez dans la sortie pour trouver des chemins erronés. Dans mon cas, la commande d'origine:
g ++ -v "d: /UW_Work/EasyUnit/examples/1-BasicUnitTesting/main.cpp"
sortie générée, y compris ce petit bijou:
-ipréfixe c:\olimexods\yagarto\arm-aucun-eabi\bin\../ lib/gcc/arm-none-eabi/4.5.1 /
ce qui expliquerait le message "pas de tel fichier ou répertoire".
Le segment "../lib/gcc/arm-none-eabi/4.5.1/" provient des spécifications intégrées:
g ++ -dumpspecs
Ce problème peut survenir si vous avez différentes versions de programmes.
Par exemple, vous avez gcc âgé d'un an et vous souhaitez compiler un code source C++. Si vous utilisez mingw-get pour installer g++, gcc et g++ auront soudainement des versions différentes et vous risquez de vous retrouver dans cette situation.
Exécuter mingw-get update et mingw-get upgrade a résolu ce problème pour moi.
Ajoutez E:\MinGW\bin à la variable PATH.
Bien que post soit vieux, j'ai eu le même problème avec mingw32 vers 4.8.1 le 2015/02/13. La compilation avec Eclipse CDT a échoué avec ce message. La tentative de ligne de commande avec l'option -v a également échoué. Il me manquait également l'exécutable cc1plus.
La cause: J'ai téléchargé le programme d’installation en ligne de commande et graphique à partir du site mingw32. Je l'ai utilisé pour faire mon installation initiale de mingw32. En utilisant l'interface graphique, j'ai sélectionné les outils de base, en sélectionnant les compilateurs c et c ++.
Ce programme d’installation a effectué une installation incomplète du compilateur 32 bits c ++. J'ai eu les fichiers g ++ et cpp mais pas l'exécutable cc1plus. Essayer de faire une «mise à jour» a échoué parce que l’installateur supposait que tout était installé.
Pour réparer, j'ai trouvé les sites suivants: http://mingw-w64.sourceforge.net/http://sourceforge.net/projects/mingw-w64/ J'ai téléchargé et exécuté cette "installation en ligne". Bien sûr, celui-ci contenait les fichiers manquants. J'ai modifié ma variable PATH et pointé vers le dossier 'bin' contenant l'exécutable g ++. Redémarré. Installé Eclipse 64 bits. Eclipse ouvert et le programme 'Hello World' c ++ compilé, exécuté et débogué correctement.
Remarque: le programme d'installation 64 bits semble utiliser les paramètres UNIX par défaut. Pourquoi un installateur ne peut-il pas déterminer le système d'exploitation ??? Assurez-vous de les changer.
J'ai passé toute une soirée à régler ce problème. J'espère que ça aide quelqu'un.
J'ai eu le même problème.
J’avais déjà un compilateur g ++ installé dans MinGW (le paquet mingw32-gcc-g ++ ) mais j’avais besoin d’un compilateur C, j’ai donc lancé mingw-get-setup.exe où j’ai pu le faire installer le mingw32 -base package, celui avec le compilateur C.
Hélas! J'ai eu cette erreur lorsque j'utilise gcc pour compiler:
gcc: erreur: processus de création: aucun fichier ni répertoire de ce type
Ce que j’ai fait, c’est, toujours avec MinGW Installation Manager, que j’ai supprimé les packages de compilateur C et C++, à savoir mingw32-base et mingw32-gcc-g ++ , et a supprimé également le répertoire C:\MinGW. Ensuite, je répète mingw-get-setup.exe, installé mingw32-base , et voilà, ça a marché :)
J'ai eu le même problème (je cours de cygwin)
Démarrer un Shell via cygwin.bat n'a pas aidé, mais le démarrage d'un Shell via MingWShell l'a été. Je ne sais pas trop pourquoi, mais je pense que cela a quelque chose à voir avec la couche supplémentaire que cygwin met entre le script en cours d'exécution et le système de fichiers sous-jacent.
J'exécutais pip install depuis cygwin d'un env virtuel pour installer Django Sentry.
Il semble y avoir quelques distributions de release pour MinGW. Lequel avez-vous essayé? Pour mémoire, j'ai rencontré exactement le même problème que l'OP et la distribution que j'ai obtenue provenait de TDM-GCC 4.5.1.
J'ai trouvé la distribution MinGW ici semble fonctionner beaucoup mieux et mettre les choses en place correctement. Donc, pour tous ceux qui rencontrent cette erreur retardée et ne peuvent pas faire fonctionner les choses, désinstallez votre MinGW existant et essayez celui que j'ai lié à la place.
J'ai eu le même problème et j'ai tout essayé sans résultat. Ce qui a résolu le problème, c'est de changer l'ordre des chemins de bibliothèque dans la variable PATH. J'avais cygwin ainsi que d'autres compilateurs, il y avait donc probablement une sorte de conflit entre eux. Ce que j'ai fait a été de mettre le C:\MinGW\bin; chemin d'abord avant tous les autres chemins et cela a résolu le problème pour moi!
(Se référant au problème initial)
Version actuelle de mingw (voir date de publication)
Tout ce que je devais faire était de définir le chemin dans le même shell dans lequel j'avais exécuté gcc.
Il m'a fallu une heure pour me rappeler comment régler le 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
essayez de mettre le chemin dans les variables système au lieu de mettre les variables utilisateur dans les variables d'environnement.
Je recevais ce message d'erreur parce que j'utilisais MinGW-w64 et que les commandes dans <install path>\bin avaient toutes un préfixe étrange. J'ai tenté d'appeler des exécutables dans les répertoires "alias cible" au lieu des répertoires <install path>\bin, ce qui a entraîné encore plus de problèmes. C'est un non-non selon le FAQ . La solution pour moi était donc de créer des liens symboliques vers toutes les commandes préfixées. J'ai ouvert une invite de commande élevée et utilisé quelque chose comme mklink gcc.exe x86_64-w64-mingw32-gcc.exe pour chaque exécutable, et maintenant ma construction fonctionne.