Gcc error createprocess no such file or directory

I had a very long path, and there’s a file in there somewhere (not gcc.exe) but another file, that gcc.exe is accessing from the path..

So when I cleared the path, it worked

C:MinGW>cd bin


C:MinGWbin>where gcc.exe
C:MinGWbingcc.exe
C:Perl64sitebingcc.exe

^^ So running gcc from there will definitely run the ming gcc.exe

C:MinGWbin>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);
}

Compiling it I got this error

C:MinGWbin>gcc file6.c
gcc: error: CreateProcess: No such file or directory

My PATH was huge

C:MinGWbin>path
PATH=C:Windowssystem32;C:Windows;C:Windowssystem32wbem;C:P......

C:MinGWbin>path | grep -io «ming»

It didn’t have ming there.

C:MinGWbin>echo MING | grep -io «ming»
MING

(and yeah that grep works..the path didn’t have ming there)

Clearing my path completely, led it to work!

C:MinGWbin>set PATH=

C:MinGWbin>gcc file6.c

C:MinGWbin>

So, it’s not clear yet precisely what it was in the PATH that led to the clash. What directory, what file.

Update-

The above seems to be correct to me but to add, it’s also not a simple case of something earlier in the path clashing.. because normally the current directory takes precedence. And it does here in so far as gcc —version shows it’s running the ming one and not one of the ones in a conflicting directory. So there’s something funny going on that, if the conflicting directory is in the path) , one has to either do .gcc or add . to the start of the path or add c:MinGWbin before any conflicting directories in the path. this is the case even when you’re in C:MinGWbin and that’s strange. And when it gives an error, it is still running Ming’s gcc but (For some reason) looking at the conflicting directory too, as I see from process monitor. There may be more of an answer here http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista in the link mentioned in the very upvoted answer here

That’s Ming32 bit..

Looking at Ming 64bit, probably has te same issue, but I see, interestingly, it comes with a bat file that (sensibly) actually puts the bin directory at the tart of the path. And it looks like that is a standard way of running Ming gcc properly.

The code::blocks IDE (sensibly) also puts the bin directory at the start of the path. If you run a C program that shows environment variables then you see that.

-edit- it seems to be a problem with path and not being able to find its bin/ folder. Even though the g++ is in that bin directory.

I am trying to launch g++ on windows in my app but i get the error below. How do i fix it? side note i can do g++ dummy.cpp in the prompt with no problem.

args -o file.exe -x c++ -

stdout

: CreateProcess: No such file or directory

-edit- my code is…

#include <windows.h> 
#include <stdio.h> 
#include <strsafe.h>

#include <ios>
#include <iostream>
#include <fstream>
#include <sstream>
#include <exception>
#include <string>
#include <deque>
#include <stdio.h>
#include <stdlib.h>

using namespace std;

string gcc_bin="E:/dev/external/MinGW/bin/g++.exe";
string gcc_folder="E:/dev/external/MinGW/bin/";

int launch_gcc(ostringstream&o);
int main(){
    ostringstream osz;
    osz << "#include <cstdio>" << endl << "int main(){ printf("hello"); } return 4; }";
    {
        launch_gcc(osz);
    }
    return 0;
}





void ErrorExit(PTSTR);
int launch_gcc(ostringstream&o)
{

    char buf2[4096];
char buf[4096];
ExpandEnvironmentStrings("%PATH%", buf, 4095);
OutputDebugString(buf);

    sprintf(buf2, "PATH=%s;%s;", gcc_folder.c_str(), buf);

    STARTUPINFO startupInfo;
    PROCESS_INFORMATION processInformation;

    HANDLE g_hChildStd_IN_Rd = NULL;
    HANDLE g_hChildStd_IN_Wr = NULL;
    HANDLE g_hChildStd_OUT_Rd = NULL;
    HANDLE g_hChildStd_OUT_Wr = NULL;
    HANDLE g_hChildStd_ERR_Rd = NULL;
    HANDLE g_hChildStd_ERR_Wr = NULL;

    HANDLE g_hInputFile = NULL;

    SECURITY_ATTRIBUTES saAttr;  
    saAttr.nLength = sizeof(SECURITY_ATTRIBUTES); 
    saAttr.bInheritHandle = TRUE; 
    saAttr.lpSecurityDescriptor = NULL; 

    if ( ! CreatePipe(&g_hChildStd_OUT_Rd, &g_hChildStd_OUT_Wr, &saAttr, 0) ) 
    ErrorExit(TEXT("StdoutRd CreatePipe")); 
    if ( ! SetHandleInformation(g_hChildStd_OUT_Rd, HANDLE_FLAG_INHERIT, 0) )
    ErrorExit(TEXT("Stdout SetHandleInformation"));

    if ( ! CreatePipe(&g_hChildStd_ERR_Rd, &g_hChildStd_ERR_Wr, &saAttr, 0) ) 
    ErrorExit(TEXT("StderrRd CreatePipe")); 
    if ( ! SetHandleInformation(g_hChildStd_OUT_Rd, HANDLE_FLAG_INHERIT, 0) )
    ErrorExit(TEXT("Stderr SetHandleInformation"));

    if (! CreatePipe(&g_hChildStd_IN_Rd, &g_hChildStd_IN_Wr, &saAttr, 0)) 
    ErrorExit(TEXT("Stdin CreatePipe")); 
    if ( ! SetHandleInformation(g_hChildStd_IN_Wr, HANDLE_FLAG_INHERIT, 0) )
    ErrorExit(TEXT("Stdin SetHandleInformation")); 

    ZeroMemory( &startupInfo, sizeof(STARTUPINFO) );
    startupInfo.cb = sizeof(STARTUPINFOA); 
    startupInfo.hStdError = g_hChildStd_OUT_Wr;
    startupInfo.hStdOutput = g_hChildStd_ERR_Wr;
    startupInfo.hStdInput = g_hChildStd_IN_Rd;
    startupInfo.dwFlags |= STARTF_USESTDHANDLES;

    ZeroMemory( &processInformation, sizeof(PROCESS_INFORMATION) );

    bool bSuccess = CreateProcess(
        gcc_bin.c_str(),
        " -o "c:/dev/src/git/myprj/theout.exe" -x c++ -",
0,
  0,
  1,
  NORMAL_PRIORITY_CLASS,
  0,//buf2,
  0,//gcc_folder.c_str(),
  &startupInfo,
  &processInformation
);
   if ( ! bSuccess ) 
      ErrorExit(TEXT("CreateProcess"));
   else 
   {
      // Close handles to the child process and its primary thread.
      // Some applications might keep these handles to monitor the status
      // of the child process, for example. 

      CloseHandle(processInformation.hProcess);
      CloseHandle(processInformation.hThread);
   }


    { 
    DWORD dwRead, dwWritten; 
    BOOL bSuccess = FALSE;

    auto sz=o.str();
    bSuccess = WriteFile(g_hChildStd_IN_Wr, sz.c_str(), sz.size(), &dwWritten, NULL);
    //if ( ! bSuccess ) break; 

    if ( ! CloseHandle(g_hChildStd_IN_Wr) ) 
        ErrorExit(TEXT("StdInWr CloseHandle")); 
    } 



    #define BUFSIZE 1024*4
    { 
    DWORD dwRead, dwWritten; 
    CHAR chBuf[BUFSIZE]; 
    BOOL bSuccess = FALSE;
    HANDLE hParentStdOut = GetStdHandle(STD_OUTPUT_HANDLE);

    chBuf[0]=0;
    if (!CloseHandle(g_hChildStd_OUT_Wr)) 
        ErrorExit(TEXT("StdOutWr CloseHandle")); 

    for (;;) 
    { 
        bSuccess = ReadFile( g_hChildStd_OUT_Rd, chBuf, BUFSIZE, &dwRead, NULL);
        if( ! bSuccess || dwRead == 0 ) break; 

        bSuccess = WriteFile(hParentStdOut, chBuf, 
                            dwRead, &dwWritten, NULL);
        chBuf[dwWritten]=0;
        if (! bSuccess ){ 
            printf("%s", chBuf);
            break; 
        }
    } 
    }

    { 
    DWORD dwRead, dwWritten; 
    CHAR chBuf[BUFSIZE]; 
    BOOL bSuccess = FALSE;
    HANDLE hParentStdErr = GetStdHandle(STD_ERROR_HANDLE);

    if (!CloseHandle(g_hChildStd_ERR_Wr)) 
        ErrorExit(TEXT("StdOutWr CloseHandle")); 

    for (;;) 
    { 
        bSuccess = ReadFile( g_hChildStd_ERR_Rd, chBuf, BUFSIZE, &dwRead, NULL);
        if( ! bSuccess || dwRead == 0 ) break; 

        bSuccess = WriteFile(hParentStdErr, chBuf, 
                            dwRead, &dwWritten, NULL);
        chBuf[dwWritten]=0;
        if (! bSuccess ){ 
            printf("%s", chBuf);
            break; 
        }
    }
    auto a=1;
    }


    return 0;
}

void ErrorExit(PTSTR lpszFunction) 
{ 
    LPVOID lpMsgBuf;
    LPVOID lpDisplayBuf;
    DWORD dw = GetLastError(); 

    FormatMessage(
        FORMAT_MESSAGE_ALLOCATE_BUFFER | 
        FORMAT_MESSAGE_FROM_SYSTEM |
        FORMAT_MESSAGE_IGNORE_INSERTS,
        NULL,
        dw,
        MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT),
        (LPTSTR) &lpMsgBuf,
        0, NULL );

    lpDisplayBuf = (LPVOID)LocalAlloc(LMEM_ZEROINIT, 
        (lstrlen((LPCTSTR)lpMsgBuf)+lstrlen((LPCTSTR)lpszFunction)+40)*sizeof(TCHAR)); 
    StringCchPrintf((LPTSTR)lpDisplayBuf, 
        LocalSize(lpDisplayBuf) / sizeof(TCHAR),
        TEXT("%s failed with error %d: %s"), 
        lpszFunction, dw, lpMsgBuf); 
    MessageBox(NULL, (LPCTSTR)lpDisplayBuf, TEXT("Error"), MB_OK); 

    LocalFree(lpMsgBuf);
    LocalFree(lpDisplayBuf);
    ExitProcess(1);
}

Common C++ Error Messages #1 – No such file or directory

Introduction

In this intermittent series, I’ll be looking at the most common error messages your C++ compiler (and linker) can produce, explaining exactly what they mean, and showing how they can be fixed (or, better still avoided). The article will specifically talk about the errors produced by the GCC command line compiler, but I’ll occasionally provide some coverage of Microsoft C++ as well. The articles are aimed at beginner to intermediate C++ programmers, and will mostly not be OS-specific.

Error Messages 101

Compiler error messages from the GCC g++ compiler generally look like something this:

which was produced by this code:

The first line of the error says which function the following error(s) is in. The error message itself comes in four main parts; the file the error occurs in, the line number and character offset at which the compiler thinks the error occurs, the fact that it is an error, and not a warning, and the text of the message.

As well as error, the compiler can also produce warnings. These are usually about constructs that, while not being actually illegal in C++, are considered dubious, or constructs that the compiler has extensions to cover. In almost all cases, you don’t want to use such constructs, and you should treat warnings as errors; in other words, your code should always compile with zero warnings. You should also increase the level of warnings from the compiler’s default, which is usually too low. With g++, you should use at least the -Wall and -Wextra compiler options to do this:

No such file or directory

The error I’m looking at today most commonly occurs when you are including a header file using the preprocessor #include directive. For example, suppose you have the following code in a file called myfile.cpp:

and you get the following error message:

What could be causing it? Well, the basic cause is that the compiler cannot find a file called myheader.h in the directories it searches when processing the #include directive. This could be so for a number of reasons.

The simplest reason is that you want the compiler to look for myheader.h in the same directory as the myfile.cpp source file, but it can’t find it. this may be because you simply haven’t created the header file yet, but the more common reason is that you either misspelled the header file name in the #include directive, or that you made a mistake in naming the header file when you created it with your editor. Look very closely at the names in both the C++ source and in your source code directory listing. You may be tempted to think «I know that file is there!», but if the compiler says it isn’t there, then it isn’t, no matter how sure you are that it is.

This problem is somewhat greater on Unix-like system, such as Linux, as there file names are character case sensitive, so Myheader.h, MyHeader.h, myheader.h and so on would all name different files, and if you get the case wrong, the compiler will not look for something «similar». For this reason, a very good rule of thumb is:

Never use mixed case when naming C++ source and header files. Use only alphanumeric characters and the underscore when naming C+++ files. Never include spaces or other special characters in file names.

Apart from avoiding file not found errors, this will also make life much easier if you are porting your code to other operating systems which may or may not respect character case.

The wrong directory?

Another situation where you may get this error message is if you have split your header files up from your C++ source files into separate directories. This is generally good practice, but can cause problems. Suppose your C++ project is rooted at C:/myprojects/aproject, and that in the aproject directory you have two sub-directorys called src (for the .cpp files) and inc (for the header files), and you put myfile.cpp in the src directory, and myheader.h in the inc directory, so that you have this setup:

Now if you compile the source myfile.cpp from the src directory, you will get the «No such file or directory» error message. The C++ compiler knows nothing about the directory structures of your project, and won’t look in the inc directory for the header. You need to tell it to look there somehow.

One thing some people try when faced with this problem is to re-write myfile.cpp so it looks like this:

or the slightly more sophisticated:

Both of these are a bad idea, as they tie your C++ code to the project’s directory structure and/or location, both of which you will probably want to change at some point in the future. If the directory structure does change, you will have to edit all your #include directories.The better way to deal with this problem is to tell the compiler directly where to look for header files. You can do that with the compiler’s -I option, which tells the compiler to look in the specified directory, as well as the ones it normally searches:

Now the original #include directive:

will work, and if your directory structure changes you need only modify the compiler command line. Of course, writing such command lines is error prone, and you should put such stuff in a makefile, the use of which is unfortunately outside the scope of this article.

Problems with libraries

Somewhat similar issues to those described above can occur when you want to use a third-party library. Suppose you want to use the excellent random number generating facilities of the Boost library. If you are copying example code, you may well end up with something like this in your C++ source file:

This will in all probability lead to yet another «No such file or directory» message, as once again the compiler does not know where «boost/random.hpp» is supposed to be. In fact, it is one of the subdirectories of the Boost installation, and on my system I can get the #include directive to work using this command line:

where /prog/boost1461 is the root directory for my specific Boost library installation.

Can’t find C++ Standard Library files?

One last problem that beginners run into is the inability of the compiler to find header files that are part of the C++ Standard Library. One particular favourite is this one:

where you are learning C++ from a very, very old book. Modern C++ implementations have not contained a file called iostream.h for a very long time indeed, and your compiler is never going to find it. You need to use the correct, standard names for such headers (and to get a better book!):

If this still fails, then there is almost certainly something very wrong with your GCC installation. The GCC compiler looks for Standard Library files in a subdirectory of its installation, and locates that directory relative to the directory containing the compiler executable, so if the Standard Library headers are available, the compiler should always find them.

Conclusion

This article looked at the «No such file or directory» message of the GCC C++ compiler. If you get this message you should:

• Remember that the compiler is always right in situations like this.
• Look very closely at the file name to make sure it is correct.
• Avoid naming file using mixed-case or special characters.
• Use the -I compiler option to tell the compiler where to look for files.
• Make sure that GCC is correctly installed on your system.

Источник

g++:error:CreateProcess:No such file or directory #26

Whenever i try to compile my C++ program. It give error:

g++:error:CreateProcess:No such file or directory.

Please help. Thank you

The text was updated successfully, but these errors were encountered:

Window load time: 791ms
activate()
platform win32

What happens if you enter

in the command prompt?

sorry for late reply

What happens when you enter

in the command prompt?

same error
g++: error: CreateProcess : No such file or directory

Sorry for the month long reply, but I am unable to reproduce this issue so I cannot help.

I have also faced the same problem while setting up Atom for C++ on Window 10. But later I found out that my MinGW was copied from Codeblocks folder. Reinstalling the packages through official MinGW installer and adding the directory path (for my case C:MinGWbin) in

Advance System Settings>Environment Variables > Path

solved the problem for me.

please can you help me out, mine is gcc: error: create process: No such file directory

yes. i got the answer. change the gcc to g++

I have experienced this problem before. The root cause is an exe file was unziped failed with the size zero. I tried another unzip tool to solved it.

For the problem, to know how it happened is important:
CreateProcess is a API to create a process, so the error indicated that the image file used to create the process may not exist.

How to solve it:
Add «-v» flags to run gcc/g++ to compile and then, the verbose log shows. We can find which file not exists. If nothing goes wrong, we can just run the last command in the verbose log with flag «-v» to continue to check recursively.

Источник

CreateProcess: нет такого файла или каталога

Я получаю эту ошибку всякий раз, когда я пытаюсь запустить GCC вне его каталога установки ( E:MinGWbin ).

Итак, допустим я в E:code и иметь файл с именем one.c . Бегущий: gcc one.c -o one.exe даст мне эту ошибку:

единственным обходным путем является переход в каталог установки, запуск gcc оттуда и указание всех других путей. Моя переменная окружающей среды Path содержит E:MinGWbin .

любые предложения по устранению этой проблемы? Я запуск Windows XP SP3.

24 ответов

его специально сказали, что вам нужно перезагрузиться после установки переменных среды в windows для migwin.

У меня была аналогичная проблема, вызванная не установкой компилятора C++. В моем случае я собирал .cpp-файлы для расширения Python, но компилятор сначала вызывается как c:mingwbingcc — . исполняемый.

внутренне, gcc.exe заметит, что его попросили скомпилировать .файл cpp. Он попытается вызвать g++.exe и сбой с тем же сообщением об ошибке:

gcc.exe: CreateProcess: нет такого файла или каталога

по данным код:: блоки wiki, вам необходимо добавить C:MinGWlibexecgccmingw32MinGW-Version на PATH . Нет необходимости перезапускать, но вам нужно открыть другой терминал, чтобы получить новейший PATH настройки.

для MinGW-w64 это libexecgccx86_64-w64-mingw32.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:MinGWvarcachemingw-getpackages» в моей системе), затем снова запустил команду install. Он загрузил и установил недостающие части GCC (он не полностью загрузил пакет GCC-core).

Что решена моя проблема.

интересно, что mingw-get был достаточно умен, чтобы продолжить загрузку GCC-core даже после того, как я удалил файл пакета в папке кэша, а также удалил пакет mingw32-gcc.

Я думаю, что более фундаментальной проблемой было то, что, поскольку файлы GCC-core не были установлены, cc1 не было. И gcc использует cc1. Я предполагаю, что, когда gcc попытался запустить cc1, он использовал CreateProcess где-то, проходя путь cc1, который не был путем существующий файл. Таким образом, сообщение об ошибке.

у меня была точно такая же проблема.

после перепроверки моего PATH , Я понял, что установил оба Mingw (64 bit) и Cygwin (32 бит). Проблема в том, что оба Mingw и Cygwin есть g++ .

отключив пути Cygwin , ошибка исчезла.

Итак, это глупое сообщение об ошибке, потому что оно не говорит вам что файл, который он не может найти.

выполните команду еще раз с подробным флагом gcc -v чтобы увидеть, что gcc до.

в моем случае случилось так, что он пытался позвонить cc1plus . Я проверил, у меня его нет. Установил компилятор mingw на C++, а затем сделал.

получал то же сообщение об ошибке при попытке запуска из Cygwin со ссылками на установку mingw.

используя ту же установку mingw32-make-3.80.0-3.exe от http://www.mingw.org/wiki/FAQ и опция оболочки mingw из Start — > Programs — > на WinXP SP3 и gcc работает нормально.

эта проблема заключается в том, что вы используете материал суффикса верхнего регистра.C вместо строчных букв.c при компиляции с помощью Mingw GCC. Например, когда вам это нравится:

затем вы получите сообщение: gcc: CreateProcess: No such file or directory

но если вы это сделаете:

затем он работает. Я просто не знаю, почему.

У меня была такая же проблема, и ни одно из предложенных исправлений не работало для меня. Поэтому, хотя это старый поток, я думаю, что я мог бы также опубликовать свое решение, если кто-то еще найдет этот поток через Google(как и я).

для меня мне пришлось удалить MinGW / удалить папку MinGW и переустановить. После повторной установки он работает как шарм.

Я испытал аналогичную проблему. Первоначально добавление папки bin GCC в мой системный путь не решило проблему. Я нашел два решения.

первым было запустить пакетный файл, который я нашел в корне установки MinGW, mingwbuilds.летучая мышь. Он (по-видимому) запускает командную строку, настроенную правильно для запуска GCC. Во-вторых, удалить двойные кавычки из папки GCC install bin, которую я добавил в переменную пути пользователя. Я попробовал это после того, как заметил партию файл не использует двойные кавычки вокруг пути установки bin.

Я случайно нашел пакетный файл во время просмотра дерева папок установки, пытаясь найти различные исполняемые файлы, которые не запускались (в соответствии с выходом-v). Я нашел некоторую информацию о MinGW wiki,http://www.mingw.org/wiki/Getting_Started, в разделах предостережения и параметры среды, это указывает, почему установщик MinGW не настраивает систему или путь пользователя для включения папки установки. Они, похоже, подтверждают, что пакетный файл предназначен для запуска командной строки, подходящей для запуска GCC из командной строки Windows.

в «дайте человеку рыбу, накормите его на день; научите человека рыбачить, избавьтесь от него на весь уик-энд» Вена,

показывает параметры компилятора. Опция g++ — v помогает:

просмотрите выходные данные для фиктивных путей. В моем случае исходная команда:

сгенерированный выход, включая этот маленький драгоценный камень:

что объясняет сообщение «Нет такого файла или каталога».

в «../lib/gcc/arm-none-eabi/ 4.5.1 / » сегмент исходит из встроенных спецификаций:

у меня был очень длинный путь, и где-то там есть файл (не gcc.exe) но другой файл, этот gcc.exe получает доступ из пути..

поэтому, когда я очистил путь, он работал

^^ таким образом, запуск gcc оттуда определенно запустит gcc ming.exe

компиляция я получил эту ошибку

мой путь был огромен

C:MinGWbin > путь / grep-io «ming»

у него не было мин там.

C:MinGWbin > Эхо мин / grep-io » мин» Минг!—9—>

(и да, что grep работает..путь не есть мин есть)

очистка моего пути полностью, привел его к работе!

Итак, пока не ясно, что именно было на пути, который привел к столкновению. Какой каталог, какой файл.

обновление-

выше, кажется, правильно для меня, но добавить, это также не простой случай чего-то ранее на пути столкнулись.. потому что обычно текущий каталог имеет приоритет. И это происходит здесь, поскольку GCC — version показывает, что он запускает ming, а не один из них в конфликтующем каталоге. Так что есть что-то забавное, если конфликтующий каталог находится в пути) , нужно либо сделать .gcc или добавить . к началу пути или добавить c:MinGWbin перед любыми конфликтующими каталогами в пути. это так, даже когда вы находитесь в C:MinGWbin и вот странный. И когда он дает ошибку, он все еще работает gcc Ming, но (по какой-то причине) смотрит на конфликтующий каталог, как я вижу из process monitor. Здесь может быть больше ответа http://wiki.codeblocks.org/index.php?title=Installing_MinGW_with_Vista в ссылке, упомянутой в самом ответе здесь

глядя на Ming 64bit, вероятно, имеет ту же проблему, но я вижу, интересно, что он поставляется с bat-файл, который (разумно) фактически помещает каталог bin в терпкий путь. И похоже, что это стандартный способ правильной работы Ming gcc.

Code::blocks IDE (разумно) также помещает каталог bin в начале пути. Если вы запустите программу C, которая показывает переменные среды, вы увидите это.

у меня была та же проблема, но ни одно из перечисленных в настоящее время решений не помогло сначала попробовать.

-v опция не дала никаких дополнительных подсказок.

пришлось прибегнуть к procmon и чтобы иметь возможность найти корень проблемы.

сброс g++ активность файла процесса выявила многочисленные попытки найти cc1plus исполняемый файл по разным путям. Среди них были пути к старой версии GCC.

но эта старая версия жила отдельно папка и вообще не упоминалась из новой версии, которую я пытался запустить.

наконец, устаревший путь был найден в переменной среды system %PATH%. После его удаления, новая версия работает без ошибок.

добавить E:MinGWbin до PATH переменной.

похоже, что есть несколько дистрибутивов выпуска для MinGW. Какой вам попробовать? Для записи я столкнулся с той же проблемой, что и OP, и дистрибутив, который я получил, был от TDM-GCC 4.5.1.

Я нашел дистрибутив MinGW здесь кажется, работает намного лучше и настраивает все правильно. Поэтому для тех, кто сталкивается с этой задержанной ошибкой «createprocess-no-such-file-or-directory» и не может заставить вещи работать, удалите существующий MinGW и попробуйте тот, который я связал вместо.

У меня была такая же проблема (я запускаю cygwin)

запуск оболочки через cygwin.летучая мышь не помог, но запуск снаряда через Мингшелл помог. Не совсем уверен, почему, но я думаю, что это связано с дополнительным слоем, который cygwin помещает между исполняющим скриптом и базовой файловой системой.

я запускал pip install из Cygwin виртуального env для установки Django sentry..

решение для меня-это просто:

когда вы сохраняете программу, скажем, ее имя привет.cpp положите его в папку, например,xxl сохраните вашу программу.

вырезать эту папку и поместить ее в папку bin mingw.

при вызове программы:

эта проблема может возникнуть, если у вас есть разные версии программ.

например, у вас есть 1-летний gcc и вы хотите скомпилировать исходный код на C++. Если вы используете mingw-get установка g++ , gcc и g++ внезапно будут разные версии, и вы, вероятно, окажетесь в этой ситуации.

под управлением mingw-get update и mingw-get upgrade решил этот вопрос для меня.

(ссылаясь на оригинальную проблему)
Сегодняшняя версия mingw (см. дату поста)
Все, что мне нужно было сделать, это установить путь в той же оболочке, в которой я бежал gcc .
Мне потребовался час, чтобы вспомнить, как установить DOS variables .

У меня была такая же проблема, и я пробовал все без результата, что исправило проблему для меня, это изменение порядка путей библиотеки в переменной PATH. У меня был cygwin, а также некоторые другие компиляторы, поэтому между ними, вероятно, было какое-то столкновение. Что я сделал, так это положил C:MinGWbin; путь сначала перед всеми другими путями, и это исправило проблему для меня!

попробуйте поместить путь в системные переменные вместо ввода пользовательских переменных в переменные среды.

я получал это сообщение об ошибке, потому что я использовал MinGW-w64 и команды в bin У всех был странный префикс. Я попытался вызвать исполняемые файлы в каталогах «целевой псевдоним», а не в bin каталоги, что привело к еще большим проблемам. Это нет-нет согласно часто задаваемые вопросы. Тогда решение для меня заключалось в создании символических ссылок на все команды с префиксами. Я открыл командную строку с повышенными правами и использовал что-то вроде 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, так и c++ компиляторы.

этот установщик сделал неполную установку 32-битного компилятора C++. У меня были файлы g++ и cpp, но не исполняемый файл cc1plus. Попытка сделать «обновление» не удалась, потому что установщик предположил, что у меня все установлено.

чтобы исправить я нашел эти сайты: http://mingw-w64.sourceforge.net/ http://sourceforge.net/projects/mingw-w64/ Я загрузил и запустил эту «онлайн-установку». Конечно, в этом были недостающие файлы. Я изменил переменную моего пути и указал на папку «bin», содержащую исполняемый файл g++. Перезагрузившей. Установлен 64 бит Eclipse. Открыл Eclipse и программу «Hello World» c++, скомпилированную, выполненную и отлаженную должным образом.

Примечание: 64-битный установщик, кажется, по умолчанию для настроек UNIX. Почему установщик определит ОС. Обязательно измените их.

Я провел целый вечер, занимаясь этим. Надеюсь, это кому-то поможет.

У меня была та же проблема.

У меня уже был компилятор g++, установленный через MinGW (пакет mingw32-gcc-g++) но мне нужен был компилятор C, поэтому я запустил mingw-get-setup.exe, где я смог его установить mingw32-базы пакет с компилятором.

увы! У меня была эта ошибка, когда я использую gcc для компиляции:

gcc: ошибка: createprocess: нет такого файла или каталога

Источник