I'm trying to compile a simple hello world program with dev-c++ 4.9.9.2 on WinXP. I've tried both C and C++ projects, both return the same error.
Obviously there's nothing wrong with the program itself, because I can use gcc or g++ from my command line and it compiles just fine. So I must have some dev setting wrong or something - or maybe some ad-hoc compiler settings.
Anyways, I use Dev to try to compile, and I get this:
Aha, found in compiler options a "add the following commands when calling compiler", wherein was set a "-v", which i promptly removed (and unchecked the box, since there were no other commands). As a result, that junk indeed went away, along with the "multiple target patterns" error, however it was replaced by another error (I've started a fresh project again, to make sure it's not remnant of the last stuff).
--Compile Log--
Compiler: Default compiler
Building Makefile: "C:\dp\Makefile.win"
Finding dependencies for file: C:\dp\main.c
Executing make...
make.exe -f "C:\dp\Makefile.win" all
gcc.exe -c main.c -o main.o -I"C:/Dev-Cpp/include"
gcc.exe: main.c: No such file or directory
gcc.exe: no input files
make.exe: *** [main.o] Error 1
Execution terminated
--/Compile Log--
Which seems strange because the makefile and main.c are in the same directory, and main.c definately exists. After playing around with it, I've found that if I make a new project directly in C: (C:\main.c) it has no trouble, but if I put it in a subdirectory (C:\dp\main.c) then it complains about not being able to find the file.
I'm very curious, since I have my CMD set up so that when it opens, it jumps straight to the C: directory from wherever it is, since I do a lot of work in CMD and it helps to start in the root directory, rather than some obscure temp directory 15 layers deep. So I'm wondering if it has something to do with that, and how I could work around that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Aha! I had a registry key (intentionally placed there a year or two ago) in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\AutoRun = "cd C:\"
Also, be wary of the same location in HKEY_CURRENT_USER, as this is another place to execute cmd autorun stuff.
After removing this key, Dev-Cpp works for the Hello World program.
Thanks for your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Brilliant. Unfortunately the guy who had what looked like this problem a year ago was an anonymous poster, so we won't be able to tell him. I guess he's either fixed it or moved on by now.
Good thing you mentioned your 'fixed-up' command shell setting, it would not have rang any alarm bells with me otherwise, and I'd have told you to give up and use VC++ 2008 Express (actually that is still a better idea IMO, but its your choice).
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It is a make error (i.e. an error reported by make) rather than a compiler, linker or preprocessor error. It has failed at generating the dependencies for the makefile (a step you will not have done from the command line).
It is hard to say what you have done, but the error is reported for line 29 of makefile.win, take a look there, it may then make more sense - failing that post the content of makefile.win here. Makefile.win is generated for you by the Dev-C++ project manager - if it is incorrect it usually implies that your project is incorrect or corrupted.
You might try deleting makefile.win to force Dev-C++ to rebuild it. If it then still fails in the same way, the problem is with the project.
"Multiple target patterns" means that there is more than one rule in the make file matching main2.o. i.e. it has more than one way to build it and cannot choose.
Perhaps the quickest way to resolve this is to create a new empty project and add your source it, and simply discard teh old corrupted one.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That very large block of text near the end, starting with "main2.o: main2.c onfigure" and ending with "includeEnd of search list." is line 29, the line that it highlights and complains about.
This is with a fresh project, fresh location, fresh makefile (that is to say, none existed, it had to generate its own), and fresh "hello world" code (or as fresh as Hello World gets)
It seems to be complaining about mingw or something. Idunno, looks like a really long block of text with compiler arguments/parameters that I have yet to understand (starting with "onfigure", which looks like a decapitated "configure")
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The dependency generation uses the C pre-processor to generate dependencies, however it is somewhat simplistic at parsing the cpp output, which if not in the expected form will confuse the parser and it will simply dump the output into the make file regardless of whether it makes any sense - which in this case it does not.
A similar problem occurred regularly back in 2004 (search forum on "multiple target patterns"), but the specific cause was fixed in later versions. At that time, if for some reason the C-preprocessor pass of your code threw up errors or warnings, the error message would get put into the make file as if it were dependency text.
I did a little experimentation with the pre-processor. If you were to do the following from the command line:
You will probably get a clean set of dependencies. However Dev-C++ has to provide the exact command line that will be used for the real compilation in order that any switch dependent macros are correctly defined. So in your case the actual dependency generation command would be:
Which you should find outputs text that looks unsurprisingly similar to the 'junk' in your makefile. The problem is the -v option which according to the manual means;
Print (on standard error output) the commands executed to run the stages
of compilation. Also print the version number of the compiler driver program
and of the preprocessor and the compiler proper.
Now I cannot think of one good reason why you might want that option set, and removing it will no doubt fix your problem.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There have been smilar problems reported from time-to-time, but as far as I recall no answer was found. A similar problem occurs when a project is placed in a folder under c:\dev-cpp\, but that seems to be a diffenert issue.
The last time this came up I believe we got close but the OP gave up (justifiably in my opinion, it is simpler to just use another - better - tool). Here it is: https://sourceforge.net/forum/message.php?msg_id=4176985 . It is possibly relevant because teh conclusion I came to was that somehow the CWD was getting switched to C:\ during the build. So you may be right. Exactly how did you set cmd.exe to start in c:\? I suggest that if you have simply set the working directory in a shortcut property sheet that it should have no effect, since make would not execute cmd through the same shortcut. If however you have performed some registry voodoo to force an autorun script when cmd.exe starts then I suggest that you have indeed broken it by doing that!
Creating a shortcut is probably a better way to coercing a specific environment of cmd.exe since all teh settings can be determined by command line parameters rather than globally. If all you want to be able to do is open cmd.exe at a path of your choice, I can recommend the "Open Command Window Here" power toy: http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
If this was your problem, you may have solved a long running problem, so please report back.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to compile a simple hello world program with dev-c++ 4.9.9.2 on WinXP. I've tried both C and C++ projects, both return the same error.
Obviously there's nothing wrong with the program itself, because I can use gcc or g++ from my command line and it compiles just fine. So I must have some dev setting wrong or something - or maybe some ad-hoc compiler settings.
Anyways, I use Dev to try to compile, and I get this:
29 C:\dp\dc\Makefile.win [Build Error] *** multiple target patterns. Stop.
Or the Compiler Log says this:
Compiler: Default compiler
Building Makefile: "C:\dp\dc\Makefile.win"
Finding dependencies for file: C:\dp\dc\main2.cpp
Executing make...
make.exe -f "C:\dp\dc\Makefile.win" all
C:\dp\dc\Makefile.win:29: *** multiple target patterns. Stop.
Execution terminated
Any help getting Dev working would be greatly appreciated.
-IsmAvatar
Aha, found in compiler options a "add the following commands when calling compiler", wherein was set a "-v", which i promptly removed (and unchecked the box, since there were no other commands). As a result, that junk indeed went away, along with the "multiple target patterns" error, however it was replaced by another error (I've started a fresh project again, to make sure it's not remnant of the last stuff).
--Compile Log--
Compiler: Default compiler
Building Makefile: "C:\dp\Makefile.win"
Finding dependencies for file: C:\dp\main.c
Executing make...
make.exe -f "C:\dp\Makefile.win" all
gcc.exe -c main.c -o main.o -I"C:/Dev-Cpp/include"
gcc.exe: main.c: No such file or directory
gcc.exe: no input files
make.exe: *** [main.o] Error 1
Execution terminated
--/Compile Log--
Which seems strange because the makefile and main.c are in the same directory, and main.c definately exists. After playing around with it, I've found that if I make a new project directly in C: (C:\main.c) it has no trouble, but if I put it in a subdirectory (C:\dp\main.c) then it complains about not being able to find the file.
I'm very curious, since I have my CMD set up so that when it opens, it jumps straight to the C: directory from wherever it is, since I do a lot of work in CMD and it helps to start in the root directory, rather than some obscure temp directory 15 layers deep. So I'm wondering if it has something to do with that, and how I could work around that.
Aha! I had a registry key (intentionally placed there a year or two ago) in the following location:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor\AutoRun = "cd C:\"
Also, be wary of the same location in HKEY_CURRENT_USER, as this is another place to execute cmd autorun stuff.
After removing this key, Dev-Cpp works for the Hello World program.
Thanks for your help.
Brilliant. Unfortunately the guy who had what looked like this problem a year ago was an anonymous poster, so we won't be able to tell him. I guess he's either fixed it or moved on by now.
Good thing you mentioned your 'fixed-up' command shell setting, it would not have rang any alarm bells with me otherwise, and I'd have told you to give up and use VC++ 2008 Express (actually that is still a better idea IMO, but its your choice).
Clifford
It is a make error (i.e. an error reported by make) rather than a compiler, linker or preprocessor error. It has failed at generating the dependencies for the makefile (a step you will not have done from the command line).
It is hard to say what you have done, but the error is reported for line 29 of makefile.win, take a look there, it may then make more sense - failing that post the content of makefile.win here. Makefile.win is generated for you by the Dev-C++ project manager - if it is incorrect it usually implies that your project is incorrect or corrupted.
You might try deleting makefile.win to force Dev-C++ to rebuild it. If it then still fails in the same way, the problem is with the project.
"Multiple target patterns" means that there is more than one rule in the make file matching main2.o. i.e. it has more than one way to build it and cannot choose.
Perhaps the quickest way to resolve this is to create a new empty project and add your source it, and simply discard teh old corrupted one.
Clifford
Project: ProjectHello
Makefile created by Dev-C++ 4.9.9.2
CPP = g++.exe
CC = gcc.exe
WINDRES = windres.exe
RES =
OBJ = main2.o $(RES)
LINKOBJ = main2.o $(RES)
LIBS = -L"C:/Dev-Cpp/lib"
INCS = -I"C:/Dev-Cpp/include"
CXXINCS = -I"C:/Dev-Cpp/lib/gcc/mingw32/3.4.2/include" -I"C:/Dev-Cpp/include/c++/3.4.2/backward" -I"C:/Dev-Cpp/include/c++/3.4.2/mingw32" -I"C:/Dev-Cpp/include/c++/3.4.2" -I"C:/Dev-Cpp/include"
BIN = ProjectHello.exe
CXXFLAGS = $(CXXINCS) -v
CFLAGS = $(INCS) -v
RM = rm -f
.PHONY: all all-before all-after clean clean-custom
all: all-before ProjectHello.exe all-after
clean: clean-custom
${RM} $(OBJ) $(BIN)
$(BIN): $(OBJ)
$(CC) $(LINKOBJ) -o "ProjectHello.exe" $(LIBS)
main2.o: main2.c onfigure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debugThread model: win32gcc version 3.4.2 (mingw-special) C:/Dev-Cpp/Bin/../libexec/gcc/mingw32/3.4.2/cc1plus.exe -E -quiet -v -IC:/Dev-Cpp/include -iprefix C:\Dev-Cpp\Bin/../lib/gcc/mingw32/3.4.2/ -MM main2.cmain2.o: main2.c C:/Dev-Cpp/include/stdio.h C:/Dev-Cpp/include/_mingw.h C:/Dev-Cpp/include/stddef.h C:/Dev-Cpp/include/stdarg.h C:/Dev-Cpp/include/sys/types.h C:/Dev-Cpp/include/stdlib.hignoring nonexistent directory "C:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"ignoring nonexistent directory "/mingw/include/c++/3.4.2"ignoring nonexistent directory "/mingw/include/c++/3.4.2/mingw32"ignoring nonexistent directory "/mingw/include/c++/3.4.2/backward"ignoring nonexistent directory "/mingw/include"ignoring nonexistent directory "/mingw/include"ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.2/include"ignoring nonexistent directory "/mingw/mingw32/include"ignoring nonexistent directory "/mingw/include"#include "..." search starts here:#include <...> search starts here: C:/Dev-Cpp/include C:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2 C:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/mingw32 C:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/../../../../include/c++/3.4.2/backward C:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/../../../../include C:/Dev-Cpp/Bin/../lib/gcc/mingw32/3.4.2/includeEnd of search list.
$(CC) -c main2.c -o main2.o $(CFLAGS)
That very large block of text near the end, starting with "main2.o: main2.c onfigure" and ending with "includeEnd of search list." is line 29, the line that it highlights and complains about.
This is with a fresh project, fresh location, fresh makefile (that is to say, none existed, it had to generate its own), and fresh "hello world" code (or as fresh as Hello World gets)
It seems to be complaining about mingw or something. Idunno, looks like a really long block of text with compiler arguments/parameters that I have yet to understand (starting with "onfigure", which looks like a decapitated "configure")
The dependency generation uses the C pre-processor to generate dependencies, however it is somewhat simplistic at parsing the cpp output, which if not in the expected form will confuse the parser and it will simply dump the output into the make file regardless of whether it makes any sense - which in this case it does not.
A similar problem occurred regularly back in 2004 (search forum on "multiple target patterns"), but the specific cause was fixed in later versions. At that time, if for some reason the C-preprocessor pass of your code threw up errors or warnings, the error message would get put into the make file as if it were dependency text.
I did a little experimentation with the pre-processor. If you were to do the following from the command line:
c:\dev-cpp\bin\cpp -I"C:/Dev-Cpp/include" -M main2.c
You will probably get a clean set of dependencies. However Dev-C++ has to provide the exact command line that will be used for the real compilation in order that any switch dependent macros are correctly defined. So in your case the actual dependency generation command would be:
c:\dev-cpp\bin\cpp -I"C:/Dev-Cpp/include" -v -M main2.c
Which you should find outputs text that looks unsurprisingly similar to the 'junk' in your makefile. The problem is the -v option which according to the manual means;
Print (on standard error output) the commands executed to run the stages
of compilation. Also print the version number of the compiler driver program
and of the preprocessor and the compiler proper.
Now I cannot think of one good reason why you might want that option set, and removing it will no doubt fix your problem.
Clifford
There have been smilar problems reported from time-to-time, but as far as I recall no answer was found. A similar problem occurs when a project is placed in a folder under c:\dev-cpp\, but that seems to be a diffenert issue.
The last time this came up I believe we got close but the OP gave up (justifiably in my opinion, it is simpler to just use another - better - tool). Here it is: https://sourceforge.net/forum/message.php?msg_id=4176985 . It is possibly relevant because teh conclusion I came to was that somehow the CWD was getting switched to C:\ during the build. So you may be right. Exactly how did you set cmd.exe to start in c:\? I suggest that if you have simply set the working directory in a shortcut property sheet that it should have no effect, since make would not execute cmd through the same shortcut. If however you have performed some registry voodoo to force an autorun script when cmd.exe starts then I suggest that you have indeed broken it by doing that!
Creating a shortcut is probably a better way to coercing a specific environment of cmd.exe since all teh settings can be determined by command line parameters rather than globally. If all you want to be able to do is open cmd.exe at a path of your choice, I can recommend the "Open Command Window Here" power toy: http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx
If this was your problem, you may have solved a long running problem, so please report back.
Clifford