Ответ 1
В частности, он сказал, что вам нужно перезагрузиться после того, как вы установили переменные среды в windows для migwin.
Я получаю эту ошибку всякий раз, когда пытаюсь запустить GCC за пределами установочного каталога (E:\MinGW\bin
).
Итак, скажем, я в E:\code
и имею файл с именем one.c
Запуск: gcc one.c -o one.exe
даст мне эту ошибку:
gcc: CreateProcess: No such file or directory
Единственным обходным решением является переход к его установочной директории, запуск gcc оттуда и указание всех других путей. Моя переменная окружения Path
содержит E:\MinGW\bin
.
Любые предложения по устранению этой проблемы? Я запускаю Windows XP SP3.
В частности, он сказал, что вам нужно перезагрузиться после того, как вы установили переменные среды в windows для migwin.
У меня была аналогичная проблема, вызванная не установкой компилятора С++. В моем случае я компилировал файлы .cpp для расширения Python, но компилятор сначала вызывается как c:\mingw\bin\gcc.exe.
Internally, gcc.exe заметил бы, что его попросили скомпилировать .cpp файл. Он попытался вызвать g++. Exe и fail с тем же сообщением об ошибке:
gcc.exe: CreateProcess: нет такого файла или каталога
Согласно Code:: Blocks wiki, вам нужно добавить C:\MinGW\libexec\gcc\mingw32\MinGW-Version
в PATH
. Нет необходимости перезапускать, но вам нужно открыть другой терминал, чтобы получить самые новые настройки PATH
.
Для MinGW-w64 этот <mingw install directory>\libexec\gcc\x86_64-w64-mingw32\4.7.0\
У меня была эта проблема.
В моем случае проблема возникла из-за проблем при загрузке пакетов для GCC. Программа mingw-get считала, что закончила загрузку, но это не так.
Я хотел обновить GCC, поэтому я использовал mingw-get для получения более новой версии. По какой-то причине mingw-get подумал, что загрузка для определенного файла завершена, но это не так. Когда он отправился на извлечение файла, я предполагаю, что он выпустил ошибку (которую я даже не удосужился посмотреть - я просто запустил "mingw-get update && mingw-get install mingw32-gcc" и оставил его там).
Чтобы решить проблему, я удалил gcc, выполнив "mingw-get remove mingw32-gcc", а также удалил файл пакета (один из mingw-get не полностью загрузился), который был в папке кэша mingw ( "C:\MinGW\var\cache\mingw-get\packages" в моей системе), а затем снова запустить команду установки. Он загружает и устанавливает недостающие части GCC (он не полностью загрузил пакет gcc-core).
Это решило мою проблему.
Интересно, что mingw-get был достаточно умен, чтобы продолжить загрузку gcc-ядра даже после того, как я удалил файл пакета в папке кеша, а также удалил пакет mingw32-gcc.
Я думаю, что более фундаментальной проблемой было то, что, поскольку файлы gcc-core не были установлены, cc1 там не было. И gcc использует cc1. Я предполагаю, что, когда gcc попытался запустить cc1, он использовал CreateProcess где-то, проходящий путь cc1, который не был пути к существующему файлу. Таким образом, сообщение об ошибке.
У меня была точно такая же проблема.
После повторной проверки моего PATH
, я понял, что я установил как Mingw
(64 бит), так и Cygwin
(32 бит).
Проблема в том, что Mingw
и Cygwin
имеют g++
.
Отключив путь Cygwin
, ошибка исчезла.
Итак, это глупое сообщение об ошибке, потому что оно не сообщает вам, какой файл он не может найти.
Запустите команду еще раз с помощью флагового флагов gcc -v
, чтобы узнать, что такое gcc.
В моем случае это случилось, когда он пытался вызвать cc1plus
. Я проверил, у меня этого нет. Установленный компилятор Mingw С++, а затем я сделал.
Получалось такое же сообщение об ошибке при попытке запустить из Cygwin со ссылками на установку mingw.
Используя ту же самую установку mingw32-make-3.80.0-3.exe из http://www.mingw.org/wiki/FAQ и вариант оболочки mingw из Start → Программы → на WinXP SP3 и gcc работают нормально.
Эта проблема связана с тем, что вы используете заглавные суффикс stuff.C, а не в нижнем регистре stuff.c, когда компилируете его с помощью Mingw GCC. Например, когда вы делаете это так:
gcc -o stuff stuff.C
то вы получите сообщение: gcc: CreateProcess: No such file or directory
Но если вы это сделаете:
gcc -o stuff stuff.c
то это работает. Я просто не знаю, почему.
У меня была такая же проблема, и ни одна из предложенных исправлений не работала для меня. Поэтому, хотя это старый поток, я полагаю, что я мог бы также опубликовать свое решение, если кто-то еще найдет этот поток через Google (как и я).
Для меня мне пришлось удалить MinGW/удалить папку MinGW и переустановить. После повторной установки он работает как шарм.
У меня возникла аналогичная проблема. Первоначально добавление папки GCC bin на мой системный путь не помогло решить проблему. Я нашел два решения.
Первым был запуск командного файла, который я нашел в корне установки MinGW, mingwbuilds.bat. Он (по-видимому) запускает командную строку, настроенную правильно для запуска GCC. Во-вторых, было удалено двойные кавычки из папки установочного bin GCC, которые я добавил в мою переменную пути пользователя. Я попробовал это, заметив командный файл, не используя двойные кавычки вокруг пути установки bin.
Дополнительные сведения
Я случайно обнаружил командный файл при просмотре дерева установочных папок, пытаясь найти различные исполняемые файлы, которые не запускались (в соответствии с выходом -v). Я нашел некоторую информацию о wiki в MinGW, http://www.mingw.org/wiki/Getting_Started в разделах "Предостережения и настройки среды", который указывает, почему установщик MinGW не настроен путь к системе или пользователю, чтобы включить папку установки. Кажется, что они подтверждают, что командный файл предназначен для запуска командной строки, подходящей для запуска GCC из приглашения Windows.
В "дайте человеку рыбу, кормите его на день, научите человека ловить рыбу, избавиться от него на весь уик-энд",
g++ --helpпоказывает параметры компилятора. Опция g++ -v помогает:
-v Display the programs invoked by the compiler
Просмотрите выходные данные для фиктивных путей. В моем случае исходная команда:
g++ -v "d:/UW_Work/EasyUnit/examples/1-BasicUnitTesting/main.cpp"
сгенерированный вывод, включая этот маленький драгоценный камень:
-iprefix c:\olimexods\yagarto\arm-none-eabi\bin\../lib/gcc/arm-none-eabi/4.5.1/
который объяснил бы сообщение "нет такого файла или каталога".
Сегмент "../lib/gcc/arm-none-eabi/4.5.1/" исходит из встроенных спецификаций:
g++ -dumpspecs
У меня был очень длинный путь, и там где-то был файл (а не gcc.exe), а другой файл, к которому gcc.exe обращается к пути.
Итак, когда я очистил путь, он работал
C:\MinGW>cd bin
C:\MinGW\bin>where gcc.exe
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe
^^ Так что запущенный gcc оттуда обязательно запустит 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);
}
Составив его, я получил эту ошибку
C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory
Моя ПУТЬ была огромной
C:\MinGW\bin>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\system32\wbem;C:\P......
C:\MinGW\bin > путь | grep -io "ming"
У него не было мин.
C:\MinGW\bin > эхо MING | grep -io "ming" MING
(и да, что grep работает... на пути не было ming)
Очистить мой путь полностью, заставил его работать!
C:\MinGW\bin>set PATH=
C:\MinGW\bin>gcc file6.c
C:\MinGW\bin>
Итак, пока не ясно, что именно в PATH привело к столкновению. Какой каталог, какой файл.
Update -
Вышеприведенное кажется правильным для меня, но, чтобы добавить, это также не простой случай чего-то ранее в конфликте пути.. потому что обычно текущий каталог имеет приоритет. И он здесь, поскольку gcc -version показывает, что он запускает ming, а не один из них в конфликтующем каталоге. Итак, там что-то смешное, если конфликтный каталог находится в пути), нужно либо сделать. \Gcc, либо добавить .
в начало пути, либо добавить c:\MinGW\bin
перед любыми конфликтующими каталогами в пути. это так, даже если вы находитесь в c:\MinGW\bin
и это странно. И когда он дает ошибку, он все еще запускает Ming gcc, но (по какой-то причине) также смотрит на конфликтующий каталог, как я вижу на мониторе процесса. Здесь может быть больше ответа http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista в ссылке, упомянутой в самом высоком ответе здесь
Что Ming32 бит..
Глядя на Ming 64bit, возможно, есть те же проблемы, но я вижу, что интересно, он поставляется с файлом bat, который (разумно) фактически помещает каталог bin в терпкий путь. И похоже, что это стандартный способ правильной работы Ming gcc.
Код:: блокирует IDE (разумно) также помещает каталог bin в начало пути. Если вы запустите программу C, в которой отображаются переменные среды, вы увидите это.
У меня была такая же проблема, но ни одно из перечисленных в настоящее время решений не помогло с первого раза.
-v
вариант не дал никаких дополнительных подсказок.
Пришлось прибегнуть к ProcMon, чтобы найти корень проблемы.
Dumping g++
активность файла процесса выявила многочисленные попытки найти исполняемый файл cc1plus
на разных путях. Среди них были пути к старой версии GCC.
Но эта старая версия размещалась в отдельной папке и совсем не ссылалась на новую версию, которую я пытался запустить.
Наконец, устаревший путь был найден в переменной среды% PATH%. После его удаления новая версия начала работать без ошибок.
Добавьте E:\MinGW\bin
в переменную PATH
.
Похоже, есть пара дистрибутивов релизов для MinGW. Какой из них вы попробовали? Для записи я столкнулся с той же проблемой, что и OP, и дистрибутив я получил от TDM-GCC 4.5.1.
Я нашел, что MinGW distro здесь работает намного лучше и правильно устанавливает. Поэтому для тех, кто работает в этой задержанной ошибке "createprocess-no-such-file-or-directory" и не может заставить работать, удалите существующий MinGW и попробуйте тот, с которым я связан.
У меня была та же проблема (я запускаю cygwin)
Запуск оболочки через cygwin.bat не помог, но запуск оболочки через MingWShell сделал. Не совсем понятно, почему, но я думаю, что это как-то связано с дополнительным слоем, который cygwin помещает между исполняемым script и базовой файловой системой.
Я запускал pip install из виртуального env cygwin для установки django sentry..
Решение для меня просто:
Когда вы сохраняете программу, скажем, ее имя hi.cpp помещено в папку, например. xxl затем сохраните вашу программу.
Отрежьте эту папку и поместите ее в папку bin в потоке.
Когда вы вызываете программу:
------ g++ xxl\hi.cpp --------
Эта проблема может возникнуть, если у вас разные версии программ.
Например, у вас есть 1-летний gcc
, и вы хотите скомпилировать исходный код на С++. Если вы используете mingw-get
для установки g++
, gcc
и g++
будут внезапно иметь разные версии, и вы, вероятно, окажетесь в этой ситуации.
Запуск mingw-get update
и mingw-get upgrade
решил эту проблему для меня.
(Ссылаясь на оригинальную проблему)
Сегодня версия mingw
(см. Дату публикации)
Все, что мне нужно было сделать, это установить путь в той же оболочке, в которой я запускал gcc
.
Потребовал мне час, чтобы вспомнить, как установить 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
У меня была та же проблема, и я пробовал все без каких-либо результатов. Для меня проблема заключалась в изменении порядка путей библиотеки в переменной PATH. У меня был cygwin, а также некоторые другие компиляторы, поэтому между ними, вероятно, было какое-то столкновение. То, что я сделал, это положить C:\MinGW\bin; путь сначала перед всеми другими путями, и он исправил проблему для меня!
попытайтесь поместить путь в системные переменные вместо того, чтобы помещать переменные пользователя в переменные среды.
Я получал это сообщение об ошибке, потому что использовал MinGW-w64, а команды в <install path>\bin
имели странный префикс. Я попытался вызвать исполняемые файлы в каталогах "target alias", а не в каталогах <install path>\bin
, что привело к еще большему количеству проблем. Это не-no в соответствии с часто задаваемые вопросы. Тогда решение для меня заключалось в создании символических ссылок на все префиксные команды. Я открыл командную строку с повышенными полномочиями и использовал что-то вроде mklink gcc.exe x86_64-w64-mingw32-gcc.exe
для каждого исполняемого файла, и теперь моя сборка работает.
Хотя пост старый, у меня была та же проблема с mingw32 vers 4.8.1 от 2015/02/13. С этим сообщением завершилось компиляция с использованием Eclipse CDT. Также не удалось выполнить попытку из командной строки с опцией -v. Мне также не хватает исполняемого файла cc1plus.
Причина: Я загрузил командную строку и графический установщик с сайта mingw32. Я использовал это, чтобы выполнить мою первоначальную установку mingw32. Используя GUI, я выбрал базовые инструменты, выбрав компиляторы c и С++.
Этот установщик выполнил неполную установку 32-битного компилятора С++. У меня были файлы g++ и cpp, но не исполняемый файл cc1plus. Попытка выполнить "обновление" не удалась, потому что установщик предположил, что все установлено.
Чтобы исправить я нашел эти сайты: http://mingw-w64.sourceforge.net/ http://sourceforge.net/projects/mingw-w64/ Я загрузил и выполнил эту "онлайн-установку". Конечно, в этом содержатся недостающие файлы. Я изменил свою переменную PATH и указал на папку "bin", содержащую исполняемый файл g++. Rebooted. Установлено 64-битное Eclipse. Открытые Eclipse и программа Hello С++ скомпилированы, выполнены и отлажены правильно.
Примечание. 64-разрядный установщик по умолчанию имеет настройки UNIX. Почему установщик не может определить ОС? Обязательно измените их.
Я провел целый вечер с этим. Надеюсь, это поможет кому-то.
У меня была та же проблема.
У меня уже был установлен компилятор g++ через MinGW (пакет mingw32-gcc-g++), но мне нужен компилятор C, поэтому я запустил mingw-get-setup.exe, где я смог он устанавливает пакет mingw32-base, один с компилятором C.
Увы! У меня была эта ошибка, когда я использую gcc для компиляции:
gcc: error: createprocess: нет такого файла или каталога
Что я делал, так и было, используя MinGW Installation Manager, я удалил компиляторы C и С++, а именно mingw32-base и mingw32-gcc-g++ и ТАКЖЕ удалил сам каталог C:\MinGW. Затем я повторно запустил mingw-get-setup.exe, установил mingw32-base, и voila, он работал:)