Dev-C++ version: 4.9.9.2
OS: MS Windows XP Media Edition SP2
Problem:
I have a VERY simple project consisting of three files -
main.cpp
object.cpp
object.h
the project makes up what is essentially a OOP hello world program, object.cpp/object.h contains a method for saying hello and main.cpp instatiates "object" and calls the method.
'C:\DOCUME~1\RICH' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
make.exe: *** [../TesterProject/object.o] Error 1
Execution terminated
I have made absolutely sure there are no spaces or anything of that sort in the filepaths of any of the files and the project is not saved in the installation folder of Dev-C++.
I know for certain that the g++ compiler works on my machine because i can compile the same project via command line with absolutely no problems or errors.
I cannot figure out why the compiler/linker is looking any where near "'C:\DOCUME~1\RICH'" as i have not specified anything to do with this path.
Any help would be most appreciated.
Richmore.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Turns out that it was something quite simple. The C:\DOCUME~1\RICH was the Piece of the puzzle that gave it away.
I swapped the user specific environment TEMP/TMP variable from where it was pointing "%User Profile%\Locals\Temp" to a much more simple C:\MovedTemp and voi la worked straight away. So it must have been the dodgy C:\DOCUME~1\RICH string that was causing issues, the string when converted to the full windows identifier resolves to
C:\Documents and Setting\Rich & theWife\
which is a really dumb path.
Stupid windows, tricked me into thinking well named paths/filenames were OK. I should have stuck to unix/DOS style names (all single string identifiers), my life would have been so much easier.
Anyway... thanks to Clifford for the help you pointed me directly to the culprit. Hopefully this will solve issues for other users to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you had "Richard & theWife" you'd have gotten away with it. The space would then not have been part of the 8.3 form (C:\DOCUME~1\RICHAR~1 rather than C:\DOCUME~1\RICH ). It looks like windows does not bother to 'encode' the space (which would make it not MS-DOS compatible - rather defeating the point perhaps). Then you got hit by the final insult - using a tool that uses the TEMP variable, but does not work well with spaces in paths!
I think you were entirely justified in being confused. It just smelled like an environment issue, but took me a while.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It looks distinctly like you have previously installed an older version of Dev-C++ and then installed 4.9.9.2. This can cause all sorts of problems because of incompatible configuration files that do not get deleted by the uninstall. You may also have problems using old project files in the newer version.
The clue is the inclusion of the -fdollar-in-identifiers option which is not supported by GCC 3.4.2. That is not what is causing this problem, because the tool has failed for some other reason, but it is indicative of a bad install.
The solution is to follow the instructions for performing a clean uninstall and reinstall in the "PLEASE READ BEFORE POSTING A QUESTION" thread. You may also have to re-create or edit existing .dev files to get them to work properly.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The install of 4.9.9.2 is absolutley fresh as the PC is new(ish)... absolutely no old versions of Dev-C++ or any other IDE/compiler software for c++.
The -fdollar-in-identifiers is something that I switched on within the environment (I said I tried everything) and did not switch it off again. However, this switch did not make any difference as I had the exact same problem before switching the -fdollar-in-identifiers on.
I still cannot figure out why the 'C:\DOCUME~1\RICH' is showing up, this is a path (or part thereof) that I have not set up anywhere - not within the Dev-C++ or my system variables. Would you know what it is trying to look there for?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The problem is with any project, I have tried a new empty project then adding the source code, a template project, a new empty project then re-coding the files by hand and any other project type I can think of.
I have had a look through the makefile but can't seem to see anything unusual, I am no expert however.
One thing to note (not sure if it is relevent) is the fact that if I combine all of the source files in the project into a single source file (obviously with some minor code changes) it will compile with no problems.
I will post the makefile and the .dev file once I finish work. Maybe someone a bit more knowledgeable will spot something I have missed.
Thanks for the help so far...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I must admit to being at a loss, but still note that the object file paths are relative (../TesterProject/object.o) whereas your .cpp files have no path prefix at all, but they appear to resolve to the same folder. This is unusual; in situations where the .dev and the source files are all in the same folder, only the file names usually appear, with no path prefix, relative or otherwise. I am wondering how you achieved that and whether it is symptomatic of your problem.
A few ideas that may help find the cause:
Do you have an installation of any other GNU toolchain, such as Cygwin, DJGPP, a separate MinGW installation, or even a cross-development tool? Or just anything that uses GNU make. Not all builds of make behave alike on Windows, and you may be picking up a different tool for building.
How are you compiling from the command line? Are you using the Dev-C++ makefile thus:
make -fmakefile.win all
and if not, and you try it does the build still fail? What does your environment look like when you build from the command line? I am sure you can investigate that yourself, but if you want more eyes on it execute the following from the command line:
To be able to build from the command line you have to have the path to the toolchain set in the PATH environment variable, but the Dev-C++ installer does not do that, either you have done that or some other tool has done that and again may be referencing a different toolchain.
When Dev builds it sets up the environment for the build. Unfortunately it suffixes the environment onto the existing environment (rather than prefixing it), which causes a problem if you have other GNU development tools installed with environment variables set to reference them - they will override Dev-C++'s settings.
The path C:\DOCUME~1\RICH is the MS-DOS 8.3 filename compatible alias to c:\documents and settings\rich more... (I am guessing abut the actual user name, and where I put ... could be anything, probably "My Documents" or "Application Settings" for example, both exist in that folder). In some circumstances make does not work correctly with spaces in paths (and some versions/builds/configurations are worse than others), so the path has been truncated after "rich". I am at a loss as to why the build is referencing this path, but if you have a mixed up installation picking parts from different toolchains, then all bets are off.
Clifford
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok first off is the pertinint info:
Dev-C++ version: 4.9.9.2
OS: MS Windows XP Media Edition SP2
Problem:
I have a VERY simple project consisting of three files -
main.cpp
object.cpp
object.h
the project makes up what is essentially a OOP hello world program, object.cpp/object.h contains a method for saying hello and main.cpp instatiates "object" and calls the method.
I hit compile and the error is as follows:
Compiler: Default compiler
Building Makefile: "C:\Programming\CPP\Projects\TesterProject\Makefile.win"
Executing make...
make.exe -f "C:\Programming\CPP\Projects\TesterProject\Makefile.win" all
g++.exe -c object.cpp -o ../TesterProject/object.o -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" -fdollar-in-identifiers
'C:\DOCUME~1\RICH' is not recognized as an internal or external command,
operable program or batch file.
The system cannot find the path specified.
make.exe: *** [../TesterProject/object.o] Error 1
Execution terminated
I have made absolutely sure there are no spaces or anything of that sort in the filepaths of any of the files and the project is not saved in the installation folder of Dev-C++.
I know for certain that the g++ compiler works on my machine because i can compile the same project via command line with absolutely no problems or errors.
I cannot figure out why the compiler/linker is looking any where near "'C:\DOCUME~1\RICH'" as i have not specified anything to do with this path.
Any help would be most appreciated.
Richmore.
Well, well, well. I/We have solved it.
Turns out that it was something quite simple. The C:\DOCUME~1\RICH was the Piece of the puzzle that gave it away.
I swapped the user specific environment TEMP/TMP variable from where it was pointing "%User Profile%\Locals\Temp" to a much more simple C:\MovedTemp and voi la worked straight away. So it must have been the dodgy C:\DOCUME~1\RICH string that was causing issues, the string when converted to the full windows identifier resolves to
C:\Documents and Setting\Rich & theWife\
which is a really dumb path.
Stupid windows, tricked me into thinking well named paths/filenames were OK. I should have stuck to unix/DOS style names (all single string identifiers), my life would have been so much easier.
Anyway... thanks to Clifford for the help you pointed me directly to the culprit. Hopefully this will solve issues for other users to.
>> which is a really dumb path.
Yes, I wouldn't share my login with my wife! ;-)
If you had "Richard & theWife" you'd have gotten away with it. The space would then not have been part of the 8.3 form (C:\DOCUME~1\RICHAR~1 rather than C:\DOCUME~1\RICH ). It looks like windows does not bother to 'encode' the space (which would make it not MS-DOS compatible - rather defeating the point perhaps). Then you got hit by the final insult - using a tool that uses the TEMP variable, but does not work well with spaces in paths!
I think you were entirely justified in being confused. It just smelled like an environment issue, but took me a while.
It looks distinctly like you have previously installed an older version of Dev-C++ and then installed 4.9.9.2. This can cause all sorts of problems because of incompatible configuration files that do not get deleted by the uninstall. You may also have problems using old project files in the newer version.
The clue is the inclusion of the -fdollar-in-identifiers option which is not supported by GCC 3.4.2. That is not what is causing this problem, because the tool has failed for some other reason, but it is indicative of a bad install.
The solution is to follow the instructions for performing a clean uninstall and reinstall in the "PLEASE READ BEFORE POSTING A QUESTION" thread. You may also have to re-create or edit existing .dev files to get them to work properly.
Clifford
Clifford,
The install of 4.9.9.2 is absolutley fresh as the PC is new(ish)... absolutely no old versions of Dev-C++ or any other IDE/compiler software for c++.
The -fdollar-in-identifiers is something that I switched on within the environment (I said I tried everything) and did not switch it off again. However, this switch did not make any difference as I had the exact same problem before switching the -fdollar-in-identifiers on.
I still cannot figure out why the 'C:\DOCUME~1\RICH' is showing up, this is a path (or part thereof) that I have not set up anywhere - not within the Dev-C++ or my system variables. Would you know what it is trying to look there for?
Thanks
Is it any project, or just this project?
There is something unusual about the full path to Makefile.win and the relative path to object.o.
Have you tried creating a new empty project and adding the source, or an unmodified template project?
Perhaps if you posted the generated makefile.win text and/or the project .dev file text we might see what is going on.
The problem is with any project, I have tried a new empty project then adding the source code, a template project, a new empty project then re-coding the files by hand and any other project type I can think of.
I have had a look through the makefile but can't seem to see anything unusual, I am no expert however.
One thing to note (not sure if it is relevent) is the fact that if I combine all of the source files in the project into a single source file (obviously with some minor code changes) it will compile with no problems.
I will post the makefile and the .dev file once I finish work. Maybe someone a bit more knowledgeable will spot something I have missed.
Thanks for the help so far...
Ok follows is the makefile.win text:
Project: Tester
Makefile created by Dev-C++ 4.9.9.2
CPP = g++.exe
CC = gcc.exe
WINDRES = windres.exe
RES =
OBJ = ../TesterProject/object.o ../TesterProject/main.o $(RES)
LINKOBJ = ../TesterProject/object.o ../TesterProject/main.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 = Tester.exe
CXXFLAGS = $(CXXINCS) -fdollar-in-identifiers
CFLAGS = $(INCS) -fdollar-in-identifiers
RM = rm -f
.PHONY: all all-before all-after clean clean-custom
all: all-before Tester.exe all-after
clean: clean-custom
${RM} $(OBJ) $(BIN)
$(BIN): $(OBJ)
$(CPP) $(LINKOBJ) -o "Tester.exe" $(LIBS)
../TesterProject/object.o: object.cpp
$(CPP) -c object.cpp -o ../TesterProject/object.o $(CXXFLAGS)
../TesterProject/main.o: main.cpp
$(CPP) -c main.cpp -o ../TesterProject/main.o $(CXXFLAGS)
And following is the .dev text
[Project]
FileName=Tester.dev
Name=Tester
UnitCount=3
Type=1
Ver=1
ObjFiles=
Includes=
Libs=
PrivateResource=
ResourceIncludes=
MakeIncludes=
Compiler=
CppCompiler=
Linker=
IsCpp=1
Icon=
ExeOutput=..\TesterProject
ObjectOutput=..\TesterProject
OverrideOutput=0
OverrideOutputName=Tester.exe
HostApplication=
Folders=
CommandLine=
UseCustomMakefile=0
CustomMakefile=
IncludeVersionInfo=0
SupportXPThemes=0
CompilerSet=0
CompilerSettings=0000100000000000000000
[Unit1]
FileName=object.cpp
CompileCpp=1
Folder=
Compile=1
Link=1
Priority=1000
OverrideBuildCmd=0
BuildCmd=
[Unit2]
FileName=object.h
CompileCpp=1
Folder=
Compile=1
Link=1
Priority=1000
OverrideBuildCmd=0
BuildCmd=
[Unit3]
FileName=main.cpp
CompileCpp=1
Folder=
Compile=1
Link=1
Priority=1000
OverrideBuildCmd=0
BuildCmd=$(CPP) -c main.cpp -o main.o $(CXXFLAGS)
[VersionInfo]
Major=0
Minor=1
Release=1
Build=1
LanguageID=1033
CharsetID=1252
CompanyName=
FileVersion=
FileDescription=Developed using the Dev-C++ IDE
InternalName=
LegalCopyright=
LegalTrademarks=
OriginalFilename=
ProductName=
ProductVersion=
AutoIncBuildNr=0
I'm not too sure what to be looking for in either of these files with regards errors or "dodgy" bits.
Just to re-iterate, the code in all of the project files is valid and correct, it will compile outside of the IDE at command line.
I am now completely at a loss, I can't think of anything to solve this.
I must admit to being at a loss, but still note that the object file paths are relative (../TesterProject/object.o) whereas your .cpp files have no path prefix at all, but they appear to resolve to the same folder. This is unusual; in situations where the .dev and the source files are all in the same folder, only the file names usually appear, with no path prefix, relative or otherwise. I am wondering how you achieved that and whether it is symptomatic of your problem.
A few ideas that may help find the cause:
Do you have an installation of any other GNU toolchain, such as Cygwin, DJGPP, a separate MinGW installation, or even a cross-development tool? Or just anything that uses GNU make. Not all builds of make behave alike on Windows, and you may be picking up a different tool for building.
How are you compiling from the command line? Are you using the Dev-C++ makefile thus:
make -fmakefile.win all
and if not, and you try it does the build still fail? What does your environment look like when you build from the command line? I am sure you can investigate that yourself, but if you want more eyes on it execute the following from the command line:
set>env.txt
and post the content of env.txt here. Be aware that your environment may contain information that you would not wish to expose, so you may want to edit it. I guess what we are interested in is the PATH and any variables listed here: http://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Environment-Variables.html#Environment-Variables or here: http://www.gnu.org/software/binutils/manual/ld-2.9.1/html_mono/ld.html#SEC4
To be able to build from the command line you have to have the path to the toolchain set in the PATH environment variable, but the Dev-C++ installer does not do that, either you have done that or some other tool has done that and again may be referencing a different toolchain.
When Dev builds it sets up the environment for the build. Unfortunately it suffixes the environment onto the existing environment (rather than prefixing it), which causes a problem if you have other GNU development tools installed with environment variables set to reference them - they will override Dev-C++'s settings.
The path C:\DOCUME~1\RICH is the MS-DOS 8.3 filename compatible alias to c:\documents and settings\rich more... (I am guessing abut the actual user name, and where I put ... could be anything, probably "My Documents" or "Application Settings" for example, both exist in that folder). In some circumstances make does not work correctly with spaces in paths (and some versions/builds/configurations are worse than others), so the path has been truncated after "rich". I am at a loss as to why the build is referencing this path, but if you have a mixed up installation picking parts from different toolchains, then all bets are off.
Clifford