Compiler: Default compiler
Building Makefile: "D:\MiniTanks\source\Makefile.win"
Executing make...
make.exe -f "D:\MiniTanks\source\Makefile.win" all
g++.exe build/console.o build/file.o build/hud.o build/instance.o build/mesh.o
build/mesh_obj.o build/object.o build/scene.o build/scene_cmd.o build/tank.o
build/texture.o build/windowext_win32.o build/main.o build/core.o
build/windowext_x11.o build/matrix4.o build/mesh_cmd.o build/sound.o
build/sound_wav.o build/window_base.o build/window.o build/font.o
build/camera.o build/input.o build/source.o build/float3.o
build/object_cmd.o build/tank_cmd.o build/tankstate.o -o "..\MiniTanks.exe"
-L"D:/PROGRAMS/DEV-CPP/lib" -mwindows -lglu32 -lopengl32 -lwinmm
De opdracht of bestandsnaam is onjuist.
Execution terminated
Compilation successful
Excuse the lack of linebreaks.
Dev-C++ refuses to output EXE, no error
I'm trying to compile my project but the linker fails to output an EXE. It prints no usable error warning in the log, just "Bad command or invalid filename" or something similar (the same error you get when typing in an invalid command in a DOS console, stupid localized Dutch error strings).
This happens with default compiler, all settings default. No fancy code, no templates or other exotic stuff.
Even cleaning the project, manually deleting all object files has no effect! I suspect Dev-C++ forces some files to be skipped during compilation, because it thinks the files don't need to be recompiled.
If I go manually through all source files and edit them (add space, remove it again) and I then compile, it links fine and outputs an EXE, that runs fine.
I believe this has to do with indirect dependencies. For example, if I change a variable name in a header file, all cpp files that #include it will be rebuild. But it seems that all cpp files that indirectly rely on that header will not. The compiler will not report any errors, nor will the linker. If I edit those cpp files, then compile, it will print those errors.
I think this is made worse because I use a lot of forward declared classes, to improve compilation time and avoid cyclic dependencies.
Actually, if I type garbage in any header file, it doesn't even attempt to rebuild anything. Seems compiler, IDE, *everything* is broken.
But just a minute ago it worked fine. The mind boggles.
But just a minute ago it worked fine. The mind boggles.
Sounds like your just not linking them together. Are you using your own makefile or letting devC++ do it? I would just leave everything as the default devc++ way.
Yes, everything default.
I just re-created the project from scratch, added all source files and it found one missing reference, most likely the cause of the linker screwup. I fixed that any it now produces an executable again.
However, the file in which the function implementation was missing, is one of the files that that I edited to force a rebuild. This seems very, very troubling, it means it doesn't re-compile a file that has been changed:
1) It should recompile the source file, and all the source files that depend on it (direct and indirect).
2) It should report an unresolved reference when it links.
Second, I deleted all object files! I would expect a linker to be able to report a missing file, if that was the reason that caused the linker to abort. And when it does abort, I'd like to know. It always prints...
Is there a compiler/linker flag that I can insert to make it print _all_ errors?
[Edited by - remdul on January 7, 2008 3:37:57 PM]
I just re-created the project from scratch, added all source files and it found one missing reference, most likely the cause of the linker screwup. I fixed that any it now produces an executable again.
However, the file in which the function implementation was missing, is one of the files that that I edited to force a rebuild. This seems very, very troubling, it means it doesn't re-compile a file that has been changed:
1) It should recompile the source file, and all the source files that depend on it (direct and indirect).
2) It should report an unresolved reference when it links.
Second, I deleted all object files! I would expect a linker to be able to report a missing file, if that was the reason that caused the linker to abort. And when it does abort, I'd like to know. It always prints...
Execution terminatedCompilation successful
...regardless whether the compilation/linking succeeds or fails.Is there a compiler/linker flag that I can insert to make it print _all_ errors?
[Edited by - remdul on January 7, 2008 3:37:57 PM]
Wow. I think something is very wrong with the linker or compiler. There are things happening in my compiled program that are practically impossible, things that worked fine before, and break at random.
I'm now getting different EXEs every time I rebuild, without code changes. I'm starting to suspect it is my machine (bad RAM perhaps) or a serious compiler bug. Probably has nothing to do with Dev-C++. I know where to look now... :)
I'm now getting different EXEs every time I rebuild, without code changes. I'm starting to suspect it is my machine (bad RAM perhaps) or a serious compiler bug. Probably has nothing to do with Dev-C++. I know where to look now... :)
Quote:
g++.exe build/console.o build/file.o build/hud.o build/instance.o build/mesh.o
build/mesh_obj.o build/object.o build/scene.o build/scene_cmd.o build/tank.o
build/texture.o build/windowext_win32.o build/main.o build/core.o
build/windowext_x11.o build/matrix4.o build/mesh_cmd.o build/sound.o
build/sound_wav.o build/window_base.o build/window.o build/font.o
build/camera.o build/input.o build/source.o build/float3.o
build/object_cmd.o build/tank_cmd.o build/tankstate.o -o "..\MiniTanks.exe"
Hm...
Windows command prompt has a limitation on the number of characters inputted. If this is being executed through a batch file or directly at the command line, it will not work - you will get an error from the command prompt. ("bad command or file name"). ...This happened to me, as well.
You can use a makefile instead, which will resolve this problem, or a linker script.
I personally recommend using MSVC++ 2005 or 2008 express editions over GCC, though, if possible.
If the above still fails to work, try reinstalling the compiler and linker.
I don't think Dev-C++ is developed any more? Wikipedia states that it hasn't been updated for two years. Last time I tried it (version 5 beta), it was a horrible, buggy IDE.
Theres MSVC++ Express, or if you want open source and/or cross-platform, there's NetBeans 6.0.
Theres MSVC++ Express, or if you want open source and/or cross-platform, there's NetBeans 6.0.
Quote:Original post by Crypter
Windows command prompt has a limitation on the number of characters inputted. If this is being executed through a batch file or directly at the command line, it will not work - you will get an error from the command prompt. ("bad command or file name"). ...This happened to me, as well.
You can use a makefile instead, which will resolve this problem, or a linker script.
Damn Crypter, that makes very well sense :). In fact, I'm sure that's the case. All was working fine until I added a new source file with a long filename. Your explanation accounts for files not being compiled and the undefined behavior that follows. Thanks!
Oh, and when I rebuild my project, I didn't include some source files that weren't needed, so it explains why I managed to get a successful compile again; the command line string is now shorter...
Dev-C++ generates a makefile, so maybe selecting the the generated makefile as manual makefile might solve this.
I actually use MSVC++ 2005, but my main comp is offline for repairs/upgrade and I got bumped down to a slow comp running Windows 98, until the new parts are delivered.
@Ahnfelt: Dev-Cpp feels pretty stable now, if you disable the auto-completion stuff it runs pretty smooth. The only thing I miss is the tab-indentation of selection. Hasn't been developed for the last 2-3 years, which is a bit of a shame, could have been a good OSS alternative to MSVC200*.
i use version 4.9.9.2
and i think its the last stable verion.
bacause the lastest werson werent compile hello world samples too when i tryed it last time.
and devc will not compile the application again if it thinks its source is the some.
just modifiy tiny parts and compile it againg.
it uses obj or other resources if they are allready there.
devc is nothing other them gcc so if it stops updating i think i can write one with c++ when i find free time.
i think we realy need a c++ source version of devc .
so it can work on linux too.
hay may be one of you guys hawe free time and can make a opnsorce c++ copy of devc?
and i think its the last stable verion.
bacause the lastest werson werent compile hello world samples too when i tryed it last time.
and devc will not compile the application again if it thinks its source is the some.
just modifiy tiny parts and compile it againg.
it uses obj or other resources if they are allready there.
devc is nothing other them gcc so if it stops updating i think i can write one with c++ when i find free time.
i think we realy need a c++ source version of devc .
so it can work on linux too.
hay may be one of you guys hawe free time and can make a opnsorce c++ copy of devc?
I've once again run into this problem, so I'm going to look for a permanent solution.
Dev-Cpp already compiles and links through a makefile, so creating a makefile manually is not going to solve anything.
It appears that the command line string length is not the issue, more likely the number of arguments that can be passed to g++ (assuming Windows has an upper limit).
Now there does not seem to be a way to pass arguments to g++ by other means, so that means it is impossible to make this work, without adding such feature to g++ or removing the OS limitation.
So, I'm now planning to modify g++ to read the arguments from a text file, which should be (relatively) easy. The only question is...can I compile and link it without bumping into the same problem? Heh...
(I'm very surprised no one has come across this issue before...)
[Edited by - remdul on January 8, 2008 8:05:43 PM]
Dev-Cpp already compiles and links through a makefile, so creating a makefile manually is not going to solve anything.
It appears that the command line string length is not the issue, more likely the number of arguments that can be passed to g++ (assuming Windows has an upper limit).
Now there does not seem to be a way to pass arguments to g++ by other means, so that means it is impossible to make this work, without adding such feature to g++ or removing the OS limitation.
So, I'm now planning to modify g++ to read the arguments from a text file, which should be (relatively) easy. The only question is...can I compile and link it without bumping into the same problem? Heh...
(I'm very surprised no one has come across this issue before...)
[Edited by - remdul on January 8, 2008 8:05:43 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement