I am getting this error whenever I try to run GCC outside of its installation directory (E:\MinGW\bin).
So, let's say I am in E:\code and have a file called one.c. Running:
gcc one.c -o one.exe will give me this error:
gcc: CreateProcess: No such file or directory
The only workaround is to navigate to its installation directory, run gcc from there, and specify all the other paths. My environmental variable Path contains E:\MinGW\bin.
Any suggestions to fixing this problem? I am running Windows XP SP3.
In the "give a man a fish, feed him for a day; teach a man to fish, get rid of him for the whole weekend" vein,
g++ --helpshows compiler options. The g++ -v option helps:
-v Display the programs invoked by the compiler
Look through the output for bogus paths. In my case the original command:
g++ -v "d:/UW_Work/EasyUnit/examples/1-BasicUnitTesting/main.cpp"
generated output including this little gem:
-iprefix c:\olimexods\yagarto\arm-none-eabi\bin\../lib/gcc/arm-none-eabi/4.5.1/
which would explain the "no such file or directory" message.
The "../lib/gcc/arm-none-eabi/4.5.1/" segment is coming from built-in specs:
g++ -dumpspecs
This problem might arise if you have different versions of programs.
For instance, you have 1-year old gcc and you want to compile a C++ source code. If you use mingw-get to install g++, gcc and g++ will suddenly have different versions and you ware likely to find yourself in this situation.
Running mingw-get update and mingw-get upgrade has solved this issue for me.
I had this same problem and none of the suggested fixes worked for me. So even though this is an old thread, I figure I might as well post my solution in case someone else finds this thread through Google(like I did).
For me, I had to uninstall MinGW/delete the MinGW folder, and re-install. After re-installing it works like a charm.
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:\MinGW\bin>where gcc.exe
C:\MinGW\bin\gcc.exe
C:\Perl64\site\bin\gcc.exe
^^ So running gcc from there will definitely run the 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);
}
Compiling it I got this error
C:\MinGW\bin>gcc file6.c
gcc: error: CreateProcess: No such file or directory
My PATH was huge
C:\MinGW\bin>path
PATH=C:\Windows\system32;C:\Windows;C:\Windows\system32\wbem;C:\P......
C:\MinGW\bin>path | grep -io "ming"
It didn't have ming there.
C:\MinGW\bin>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:\MinGW\bin>set PATH=
C:\MinGW\bin>gcc file6.c
C:\MinGW\bin>
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:\MinGW\bin before any conflicting directories in the path. this is the case even when you're in C:\MinGW\bin 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.
The solution for me is simply:
When you save the program, let's say its named hi.cpp put it into folder e.g. xxl then save your program.
Cut this folder and put it into the bin folder of the mingw.
When you call the program:
------ g++ xxl\hi.cpp --------
I had exactly the same problem.
After a recheck of my PATH, I realized I installed both Mingw (64 bit) and Cygwin (32 bit).
The problem is that both Mingw and Cygwin have g++.
By deactivating the path of Cygwin, the error disappeared.
I experienced a similar problem. Initially, adding the GCC bin folder to my system path did not resolve the problem. I found two solutions.
The first was to run a batch file I found in the root of the MinGW install, mingwbuilds.bat. It (apparently) launches a command prompt configured correctly to run GCC. The second was to remove double-quotation marks from the GCC install bin folder that I had added to my user path variable. I tried this after noticing the batch file not using double-quotes around the install bin path.
Extra Details
I found the batch file accidentally while browsing the install folder tree trying to locate the various executables that weren't launching (according to the -v output). I found some information on the MinGW wiki, http://www.mingw.org/wiki/Getting_Started, in the Cautions and Environment Settings sections, that indicates why the MinGW installer does not set up the system or user path to include the install folder. These seem to confirm the batch file is intended to launch a command prompt suitable for running GCC from a Windows prompt.
According to Code::Blocks wiki, you need to add C:\MinGW\libexec\gcc\mingw32\MinGW-Version to your PATH. There is no need to restart, but you need to open another terminal in order to get the newest PATH settings.
For MinGW-w64, that's <mingw install directory>\libexec\gcc\x86_64-w64-mingw32\4.7.0\
Add E:\MinGW\bin to the PATH variable.
I had the same problem but none of currently listed solutions helped at first try.
-v option didn't give any additional clues.
Had to resort to ProcMon to be able to find the root of the problem.
Dumping g++ process file activity revealed numerous attempts to find cc1plus executable at different paths. There were paths to old GCC version among them.
But that old version resided in separate folder and was not at all referenced from the new version I tried to run.
At last the obsolete path was found in system %PATH% environment variable. After removing it, the new version started to work without errors.
I had a similar problem, caused by not installing the C++ compiler. In my case I was compiling .cpp files for a Python extension, but the compiler is first invoked as c:\mingw\bin\gcc.exe.
Internally, gcc.exe would notice it was asked to compile a .cpp file. It would try to call g++.exe and fail with the same error message:
gcc.exe: CreateProcess: no such file or directory
I was getting this error message, because I was using MinGW-w64, and the commands in <install path>\bin all had a weird prefix. I attempted to call executables in the "target alias" directories instead of in <install path>\bin directories, which resulted in even more problems. That's a no-no according to the FAQ. The solution for me, then, was to create symbolic links to all the prefixed commands. I opened an elevated command prompt and used something like mklink gcc.exe x86_64-w64-mingw32-gcc.exe for every executable, and now my build works.
I just had this problem.
In my case, the problem was due to problems when downloading the packages for GCC. The mingw-get program thought it finished the download, but it didn't.
I wanted to upgrade GCC, so I used mingw-get to get the newer version. For some reason, mingw-get thought the download for a particular file was finished, but it wasn't. When it went to extract the file, I guess it issued an error (which I didn't even bother to look -- I just ran "mingw-get update && mingw-get install mingw32-gcc" and left it there).
To solve, I removed gcc by doing "mingw-get remove mingw32-gcc" and also removed the package file (the one mingw-get didn't fully download), which was in the mingw cache folder ("C:\MinGW\var\cache\mingw-get\packages" in my system), then ran the install command again. It download and installed the missing parts of GCC (it had not fully downloaded the package gcc-core).
That solved my problem.
Interestingly enough, mingw-get was smart enough to continue the download of gcc-core even after me having deleted the package file in the cache folder, and also removed the package mingw32-gcc.
I think the more fundamental problem was that since gcc-core files were not installed, cc1 wasn't there. And gcc uses cc1. I guess that, when gcc tried to start cc1, it used CreateProcess somewhere passing the path of cc1, which was not the path of an existing file. Thus the error message.
try to put the path in the system variables instead of putting in user variables in environment variables.
For me this error started occurring when the length of the command line exceeded cygwin's limit. Which was 32000 bytes.
You can check the limit using this command:
$ getconf ARG_MAX
32000
The solution in the project I am working has not been finalized yet, but possible solutions include:
Likely there are many more possible solutions too, the simplest perhaps is finding a way to increase the length limit.
(Referring to original problem)
Today's version of mingw (see post date)
All I had to do was to set the path in same shell I ran gcc.
Took me an hour to remember how to set 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
It looks like there are a couple of release distro for MinGW. Which one did you try? For the record, I ran into the exact same problem as the OP and the distro I got was from TDM-GCC 4.5.1.
I found the MinGW distro here seems to work far better and sets things up correctly. So for anyone running into this retarded 'createprocess-no-such-file-or-directory' error and can't get things to work, uninstall your existing MinGW and try the one I linked instead.
I had the same problem and I tried everything with no result,, What fixed the problem for me was changing the order of the library paths in the PATH variable. I had cygwin as well as some other compilers so there was probably some sort of collision between them. What I did was putting the C:\MinGW\bin; path first before all other paths and it fixed the problem for me!
I had the same problem.
I already had a g++ compiler installed thru MinGW (the package mingw32-gcc-g++) but I needed a C compiler so I ran mingw-get-setup.exe where I was able to have it install the mingw32-base package, the one with the C compiler.
Alas! I had this error when I use gcc to compile:
gcc: error: createprocess: no such file or directory
What I did was, still using the MinGW Installation Manager, I removed the C and C++ compiler packages, namely mingw32-base and mingw32-gcc-g++ and ALSO deleted the C:\MinGW directory itself. Then I reran mingw-get-setup.exe, installed mingw32-base, and voila, it worked :)
This problem is because you use uppercase suffix stuff.C rather than lowercase stuff.c when you compile it with Mingw GCC. For example, when you do like this:
gcc -o stuff stuff.C
then you will get the message: gcc: CreateProcess: No such file or directory
But if you do this:
gcc -o stuff stuff.c
then it works. I just don't know why.
I had the same problem (I'm running cygwin)
Starting a shell through cygwin.bat didn't help, but starting a shell through MingWShell did. Not quite sure why, but I think it had something to do with the extra layer that cygwin puts between the executing script and the underlying filesystem.
I was running pip install from within a virtual env's cygwin to install django sentry..
Although post is old I had the same problem with mingw32 vers 4.8.1 on 2015/02/13. Compiling using Eclipse CDT failed with this message. Trying from command line with -v option also failed. I was also missing the cc1plus executable.
The cause: I downloaded the command line and graphical installer from the mingw32 site. I used this to do my initial install of mingw32. Using the GUI I selected the base tools, selecting both the c and c++ compilers.
This installer did an incomplete install of the 32 bit c++ compiler. I had the g++ and cpp files but not the cc1plus executable. Trying to do an 'update' failed because the installer assumed I had everything installed.
To fix I found these sites: http://mingw-w64.sourceforge.net/ http://sourceforge.net/projects/mingw-w64/ I downloaded and ran this 'online install'. Sure enough this one contained the missing files. I modified my PATH variable and pointed to the 'bin' folder containing the g++ executable. Rebooted. Installed 64 bit Eclipse. Opened Eclipse and the 'Hello World' c++ program compiled, executed, and debugged properly.
Note: the 64bit installer seems to default to UNIX settings. Why can't an installer determine the OS??? Make sure to change them.
I spent an entire evening dealing with this. Hope this helps someone.
Was getting the same error message when trying to run from Cygwin with links to the mingw install.
Using the same install of mingw32-make-3.80.0-3.exe from http://www.mingw.org/wiki/FAQ and the mingw shell option from Start -> Programs -> on a WinXP SP3 and gcc is working fine.
So this is a stupid error message because it doesn't tell you what file it can't find.
Run the command again with the verbose flag gcc -v to see what gcc is up to.
In my case, it happened it was trying to call cc1plus. I checked, I don't have that. Installed mingw's C++ compiler and then I did.
Source: Stackoverflow.com