gcc/g++ gives me error “CreateProcess: No such file or directory”
-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++ —
10 Answers 10
Try to add the path to g++ compiler into PATH environment variable:
At this point environment block of your process contains PATH variable that includes the path to g++ compiler. Note: this does not affect user’s environment.
You can use char instead of TCHAR , and strcpy , strcat . This way will work in both cases: with Unicode enabled and without Unicode support.
It is very likely that double instances of the compiler exist on the system.
If so, try the following for experiment so that the one under current path could run for the source compile:
Hope this could be of help. Regards.
Which GCC for windows are you using? MinGW, Cygwin, something else?
Have you tried logging in and out again as indicated in this question? CreateProcess: No such file or directory
On Windows, GCC needs its bin directory to be on the PATH, it won’t look in the directory of its own binary. Try putting something like
into your program before the call to g++ to make sure the directory is on the path for your program’s environment (if you’re not running your program in a debugger, use wprintf instead)
Watch out if you tried to install GCC on a path with a space character in it, both MinGW and Cygwin warn against this.
I have had the same issue and got it resolved after adding the «C:\MinGW\msys\1.0\bin» to the PATH system variable.
Use Sysinternals ProcessMonitor (http://technet.microsoft.com/en-us/sysinternals/bb896645) to trace the system calls that are issued by your code (CreateFile, CreateProcess, Registry queries) along with their success and return value. This also shows all different attempts to find the executable which is not found by your code — most times this makes it obvious, which mistake (e.g. typo, escaping, white-space in path etc.) caused the code not to find the g++ executable.
Use Sysinternals ProcessMonitor like BertNase said. What you do is find the .exe name that is doing the compiling under the Process Name column, like gcc.exe. Then look in the Result column and anything that is not a SUCCESS check it out. I think what you are looking for is a NAME NOT FOUND result though.
I had this same problem and did what I just mentioned above, I found that gcc.exe was getting a NAME NOT FOUND result for cc1obj.exe. So I made an educated guess and went into my MinGW folder under \libexec\gcc\mingw32\4.5.0 (the version number might not be the same for you) and made a copy of cc1.exe then renamed it as cc1obj.exe. And wala, that fixed the problem.
You probably aren’t missing the same file but it sounds like following this process will fix it.
gcc/g++: “No such file or directory”
g++ gives me errors of the form:
It is the same when compiling C-programs with gcc .
Please note: This question has been asked many times before, but each time it was specific to the askers situation. This question’s purpose is to have a question that others can be closed as duplicates of, once and for all; a FAQ.
1 Answer 1
Your compiler just tried to compile the file named foo.cc . Upon hitting line number line , the compiler finds:
The compiler then tries to find that file. For this, it uses a set of directories to look into, but within this set, there is no file bar . For an explanation of the difference between the versions of the include statement look here.
How to tell the compiler where to find it
g++ has an option -I . It lets you add include search paths to the command line. Imagine that your file bar is in a folder named frobnicate , relative to foo.cc (assume you are compiling from the directory where foo.cc is located):
You can add more include-paths; each you give is relative to the current directory. Microsoft’s compiler has a correlating option /I that works in the same way, or in Visual Studio, the folders can be set in the Property Pages of the Project, under Configuration Properties->C/C++->General->Additional Include Directories.
Now imagine you have multiple version of bar in different folders, given:
The priority with #include «bar» is leftmost:
As you see, when the compiler started looking through A/ , B/ and C/ , it stopped at the first or leftmost hit.
This is true of both forms, include <> and incude «» .
Difference between #include and #include «bar»
Usually, the #include makes it look into system folders first, the #include «xxx» makes it look into the current or custom folders first.
Imagine you have the following files in your project folder:
For this, your compiler will #include the file list in your project folder, because it currently compiles main.cc and there is that file list in the current folder.
and then g++ main.cc , your compiler will look into the system folders first, and because
is a standard header, it will #include the file named list that comes with your C++ platform as part of the standard library.
This is all a bit simplified, but should give you the basic idea.
Details on <> / «» -priorities and -I
According to the gcc-documentation, the priority for include <> is, on a «normal Unix system», as follows:
For C++ programs, it will also look in /usr/include/c++/version, first. In the above, target is the canonical name of the system GCC was configured to compile code for; [. ].
The documentation also states:
You can add to this list with the -Idir command line option. All the directories named by -I are searched, in left-to-right order, before the default directories. The only exception is when dir is already searched by default. In this case, the option is ignored and the search order for system directories remains unchanged.
To continue our #include
/ #include»list» example (same code):
and indeed, the -I. prioritizes the folder . over the system includes and we get a compiler error.
gcc fails with spawn: No such file or directory
I downloaded Ruben’s build of Cygwin GCC.
However upon running it seems unable to compile any files
As a workaround, I found this to work
7 Answers 7
I had this same problem on Cygwin64, and the solution was PATH related..kinda.
Turns out, there are copies of gcc in /usr/bin and /bin (at least, there is in my install).
Executing /bin/gcc failed with the error above — I’m guessing due to incorrectly assumed relative paths.
Executing /usr/bin/gcc works as expected!
In my case, the «problem» was that I had inadvertently injected «/bin» into my PATH environment variable, resulting in /bin/gcc being executed, instead of /usr/bin/gcc. Removing the «/bin» from the path solved the problem.
Still unclear why there are two gcc binaries (which appear to be identical) in different places. but maybe the Cygwin gurus can answer that; or maybe my installation is just foo-barred.
I had the same problem and solved it by installing the g++ package in addition to gcc-core
Ruben’s builds are not Cygwin GCC packages, rather they are cross-compilers which run on various platforms but target native Windows using the MinGW-w64 toolchain.
In any case, you shouldn’t be using them on Cygwin. If you want to compile Cygwin executables, install the gcc4 packages; if you want to cross-compile for Windows, install the mingw64-i686-gcc (for Win32) or mingw64-x86_64-gcc (for Win64) packages instead.
Gcc isn’t really the compiler. It’s a front end program that orchestrates the execution of any necessary compiler, assembler, and linker components. Typically these others are separately compiled programs.
So, gcc is trying (kind of) to tell you that it can’t find the compiler. I guess it needs to be on your PATH or in an expected location.
If you are executing this from a Windows DOS box then it definitely needs a windows PATH setting.
I like to install Cygwin, making sure to include rxvt. At that point, you can configure a purely sh(1) path and your environment is rather more civilized.
Make sure the source file extension is in lowercase (i.e. main.c, not main.C):
This only refers to the case of the extension as given to the gcc, the actual source file can have the extension in whatever case you want.
Explanation: This is from my experimenting with cygwin and gcc, I don’t know the actual reason for this behavior.
This error occurs whenever cygwin cc can’t find a required file.
For those running stuff within cygwin’s bin directly from a Windows shell, a gotcha to watch out for is that Windows allow you to run programs from the command line like this:
Notice that there is no slash between e: and cyg .
So this command would successfully start cygwin gcc from the Windows shell, but halfway through the run it will error out because some component(s) of gcc will utilize the first argument of the input e:cyg/bin/gcc and unlike mingw, this is not a valid path for cygwin gcc.
This can be fixed simply by changing the command to:
Notice the slash in between e: and cyg .
A similar gotcha is due to Windows allowing paths like e:/../folder1 as an alternative to e:/folder1 . Windows does not give you an error if you are at the root folder and try to go up another folder using .. .
So you could start running cygwin gcc using the command:
However, it would fail halfway with gcc: error: spawn: No such file or directory because some component(s) of cygwin gcc would attempt to run gcc using the first argument of the command input itself, and unlike mingw, e:/../cyg/bin/gcc is not recognized as a valid path by cygwin because you are going up a folder when there’s no folder to go up to.
As like above, this can be fixed by keeping the path valid: