Thanks Clifford, it was rm.exe that was missing. What happened was, I installed a new mingw in c:\mingw and pointed everything to that for my default compiler. It doesn't contain rm.exe, and it seems that dev-c++ doesn't put its own bin folder in the windows path variable during install or look there if it can't find an exe during compile. Maybe I have it set up wrong though. I actually have two new mingw versions and in compiler options I have one as the default and one as a second option. I think when I did that I deleted the pointers to the mingw that came with dev-c++ because I didn't want to accidentally use it. Maybe if I'd left it in there as a third option dev would still look in its own bin for rm.exe when it couldn't find it elsewhere? Because when I switch between the two I do have, it still lists them both under binaries but changes the order so that the one you want is first in each case. Anyway, for now I just copied rm.exe to my other mingw folders and it works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-01
"Rebuild all" uses rm to delete the previous build files. The log is saying that the make utility cannot find this utility. It should be in c:\dev-cpp\bin.
On Vista for some reason it is necessary to fully specify the path for the executables used by the build; unfortunately rm.exe is not one of those that can be specified in Tools->Compiler options->Programs. One solution if this is your problem is perhaps to copy rm.exe to a location that is already in Vista's PATH such as C:\Windows, or create a batch file rm.bat at sich a location that contains a fully qualified call to c:\dev-cpp\bin\rm.exe
Note also that you cannot specify an executable for ranlib.exe which is used if you build a static library, so on Vista you may have a similar problem building static library projects.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not using Vista. This is on the same XP machine as all of my previous posts. Something must have changed in my setup that broke it, because it certainly used to work.
A while back I was having the problem where my code would only recompile properly if I did rebuild all, and someone (probably Clifford) mentioned unchecking the fast but imperfect dependency thing. I guess since then I haven't used rebuild all so I never noticed the problem until now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-01
>> dev-c++ doesn't put its own bin folder in the windows path variable during install
It modifies the path dynamically - changing it only for the build session locally. It applies all those paths in Tools->Compiler->options->directories. Place tour Dev-C++ bin path last to use it when all else fails.
>> I deleted the pointers to the mingw that came with dev-c++
>> because I didn't want to accidentally use it.
You can set up multiple compiler configurations in Dev-C++ all pointing to different tool chains.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I do have the multiple compiler configurations pointing to different tool chains. I guess I don't completely understand how dev-c++ handles that. I started with the default compiler selection and changed all the bin/lib/include pointers from c:\dev-cpp\ to c:\mingw (my updated installation). Then I clicked on the button to add a new compiler set, called it mingwnu because it's for the nuwen.net version, and replaced each of the bin/lib/include directories with the c:\mingwnu versions. But now when I switch between the two sets, it displays all the folders from each compiler set, and merely reorders them so the correct one is first. It seems like if it doesn't find what it needs in mingwnu then it will default to mingw - is that true? It sounds like rather than using the replace option when setting up, I should have just used add and then put the dev-cpp folder at the bottom so it would use it only as a last resort. Then it might find rm.exe without additional intervention.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-09-01
Hmmmm.... I think you now know more about it that me! At least the work-around works. One problem with Dev-C++ is that when it temporarily modifies the path at build time, it places its paths at the end on the default path, so any executables in preceding paths that match those the build is looking for will override the project settings. This is dumb and annoying, but overcome (mostly) by using explicit paths in the programs settings - unfortunately as we have been discussing not all the utilities it uses are specified in the programs settings.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a test, I removed the copies of rm.exe that I had placed in c:\mingw\bin and c:\mingwnu\bin and added c:\dev-cpp\bin back into the list under Tools-Compiler Options-Directories-Binaries. That worked, so it seems it searches each location starting at the top. So mine is now C:\mingw\bin then C:\mingwnu\bin then C:\Dev-Cpp\bin.
One other note for anyone trying this type of setup: some mingw installs do not have a file called make.exe and this can cause problems. I installed mingw using their installer, and it put a file called mingw32-make.exe in the bin directory, but no make.exe file. It also put mingw32-gcc.exe in there, but included a copy called gcc.exe for better compatibility I guess. So if you add that bin folder to the top and leave c:\dev-cpp\bin at the bottom of your list, make will still use the make.exe in dev-cpp\bin. To fix it you could either rename or copy mingw32-make.exe to make.exe in the new mingw folder, or click on the Programs tab and select mingw32-make.exe if you want to leave the mingw install intact.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using 4.9.9.2 but with the default compiler changed to an updated version of mingw (still gcc-3.4.2 though).
My project compiles and runs fine, but if I do rebuild all I get this:
Compiler: Default compiler
Building Makefile: "C:\Bittware\chamber\TellTheMaid\Makefile.win"
Executing make clean
rm -f tell.o shared.o HomerSockets.o TellTheMaid.exe
process_begin: CreateProcess(NULL, rm -f tell.o shared.o HomerSockets.o TellTheMaid.exe, ...) failed.
make (e=2): The system cannot find the file specified.
make.exe: *** [clean] Error 2
Execution terminated
Here's the makefile:
Project: tell
Makefile created by Dev-C++ 4.9.9.2
CPP = g++.exe
CC = gcc.exe
WINDRES = windres.exe
RES =
OBJ = tell.o shared.o HomerSockets.o $(RES)
LINKOBJ = tell.o shared.o HomerSockets.o $(RES)
LIBS = -L"C:/mingw/lib" -L"C:/mingwnu/lib" -lwsock32
INCS = -I"C:/mingw/include" -I"C:/mingwnu/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 = TellTheMaid.exe
CXXFLAGS = $(CXXINCS)
CFLAGS = $(INCS)
RM = rm -f
.PHONY: all all-before all-after clean clean-custom
all: all-before TellTheMaid.exe all-after
clean: clean-custom
${RM} $(OBJ) $(BIN)
$(BIN): $(OBJ)
$(CPP) $(LINKOBJ) -o "TellTheMaid.exe" $(LIBS)
tell.o: tell.c
$(CC) -c tell.c -o tell.o $(CFLAGS)
shared.o: shared.c
$(CC) -c shared.c -o shared.o $(CFLAGS)
HomerSockets.o: HomerSockets.c
$(CC) -c HomerSockets.c -o HomerSockets.o $(CFLAGS)
Thanks Clifford, it was rm.exe that was missing. What happened was, I installed a new mingw in c:\mingw and pointed everything to that for my default compiler. It doesn't contain rm.exe, and it seems that dev-c++ doesn't put its own bin folder in the windows path variable during install or look there if it can't find an exe during compile. Maybe I have it set up wrong though. I actually have two new mingw versions and in compiler options I have one as the default and one as a second option. I think when I did that I deleted the pointers to the mingw that came with dev-c++ because I didn't want to accidentally use it. Maybe if I'd left it in there as a third option dev would still look in its own bin for rm.exe when it couldn't find it elsewhere? Because when I switch between the two I do have, it still lists them both under binaries but changes the order so that the one you want is first in each case. Anyway, for now I just copied rm.exe to my other mingw folders and it works.
Are you using Vista?
Wayne
"Rebuild all" uses rm to delete the previous build files. The log is saying that the make utility cannot find this utility. It should be in c:\dev-cpp\bin.
On Vista for some reason it is necessary to fully specify the path for the executables used by the build; unfortunately rm.exe is not one of those that can be specified in Tools->Compiler options->Programs. One solution if this is your problem is perhaps to copy rm.exe to a location that is already in Vista's PATH such as C:\Windows, or create a batch file rm.bat at sich a location that contains a fully qualified call to c:\dev-cpp\bin\rm.exe
Note also that you cannot specify an executable for ranlib.exe which is used if you build a static library, so on Vista you may have a similar problem building static library projects.
Clifford
I'm not using Vista. This is on the same XP machine as all of my previous posts. Something must have changed in my setup that broke it, because it certainly used to work.
A while back I was having the problem where my code would only recompile properly if I did rebuild all, and someone (probably Clifford) mentioned unchecking the fast but imperfect dependency thing. I guess since then I haven't used rebuild all so I never noticed the problem until now.
>> dev-c++ doesn't put its own bin folder in the windows path variable during install
It modifies the path dynamically - changing it only for the build session locally. It applies all those paths in Tools->Compiler->options->directories. Place tour Dev-C++ bin path last to use it when all else fails.
>> I deleted the pointers to the mingw that came with dev-c++
>> because I didn't want to accidentally use it.
You can set up multiple compiler configurations in Dev-C++ all pointing to different tool chains.
Clifford
I do have the multiple compiler configurations pointing to different tool chains. I guess I don't completely understand how dev-c++ handles that. I started with the default compiler selection and changed all the bin/lib/include pointers from c:\dev-cpp\ to c:\mingw (my updated installation). Then I clicked on the button to add a new compiler set, called it mingwnu because it's for the nuwen.net version, and replaced each of the bin/lib/include directories with the c:\mingwnu versions. But now when I switch between the two sets, it displays all the folders from each compiler set, and merely reorders them so the correct one is first. It seems like if it doesn't find what it needs in mingwnu then it will default to mingw - is that true? It sounds like rather than using the replace option when setting up, I should have just used add and then put the dev-cpp folder at the bottom so it would use it only as a last resort. Then it might find rm.exe without additional intervention.
Hmmmm.... I think you now know more about it that me! At least the work-around works. One problem with Dev-C++ is that when it temporarily modifies the path at build time, it places its paths at the end on the default path, so any executables in preceding paths that match those the build is looking for will override the project settings. This is dumb and annoying, but overcome (mostly) by using explicit paths in the programs settings - unfortunately as we have been discussing not all the utilities it uses are specified in the programs settings.
Clifford
As a test, I removed the copies of rm.exe that I had placed in c:\mingw\bin and c:\mingwnu\bin and added c:\dev-cpp\bin back into the list under Tools-Compiler Options-Directories-Binaries. That worked, so it seems it searches each location starting at the top. So mine is now C:\mingw\bin then C:\mingwnu\bin then C:\Dev-Cpp\bin.
One other note for anyone trying this type of setup: some mingw installs do not have a file called make.exe and this can cause problems. I installed mingw using their installer, and it put a file called mingw32-make.exe in the bin directory, but no make.exe file. It also put mingw32-gcc.exe in there, but included a copy called gcc.exe for better compatibility I guess. So if you add that bin folder to the top and leave c:\dev-cpp\bin at the bottom of your list, make will still use the make.exe in dev-cpp\bin. To fix it you could either rename or copy mingw32-make.exe to make.exe in the new mingw folder, or click on the Programs tab and select mingw32-make.exe if you want to leave the mingw install intact.