Community
Participate
Working Groups
Build Identifier: Version: Indigo Service Release 1 Build id: 20110916-0149 When I build a C project, I can see compilations launched in the console view, but each ends with an error, but no message, and no file generated: gcc -O0 -g3 -Wall -c -fmessage-length=0 -o src\Hello.o ..\src\Hello.c Build error occurred, build is stopped Time consumed: 125 ms. So I investigated to understand what was happening. I launched the compilation outside Eclipse, using the same command line as in the console view. It worked. And in verbose mode, outputs are also identical inside or outside Eclipse (except for the temporary file name of course). So, compiler, project and command line are fine. I embedded the command line in a shell, in order to have more control on what happens there. I added commands to list the content of the active configuration directory before and after compilation: the file is generated (exists after and not before). I added a command to see the return code of the compilation, it is 0. So command launched by Eclipse is fine. But after the end of the build, generated files have disapeared. If there is more than one source file in the project, compilation is launched for each one, but generated files are deleted after each, not together after the last source file. So, the problem seems to occur during the build process and due to it. Reproducible: Always Steps to Reproduce: 1. Create a new "Hello World ANSI C Project" with "Cygwin GCC" or "MinGW GCC" toolchain. 2. Build the project (using the -v option of the compiler helps to be sure of which one is used). The output directory (Debug) contains only a src subdirectory and no generated files.
It works for me on Windows 7 64 bit with 64 bit Eclipse, MinGW GCC 4.5.2. Are you running Window Server 2003 32 bit or 64 bit? You can double check in Help, About, Installation Details, Configuration, then look for -arch x86 or -arch x86_64.
-arch is x86_64 MinGW GCC is 4.6.1 Eclipse is 64 bits version with java 7.0.1 But my system is Windows XP 64 bits (I made a mistake on that field when reporting the bug). After reporting the bug, I tryed on an other PC, with a new eclipse installation (Eclipse IDE for C/C++ Developers (includes Incubating components), with nothing else), a new workspace, and a cygwin compiler, and I got the same result. I found an ugly workaround consisting mainly in - using a backup copy of generated files, - embedding the compiler in a shell, including a copy from the backup directory before compilation, and to the backup directory after compilation, - ignoring compilation errors. It is not very stable, does not report errors, builds slowly and much too often, ... But it is better than nothing ! For information, I had a few months' break in C developpments between about six months ago and one month ago, and before that break, it worked.
I tested with Cygwin and MinGW on Win XP (32 bit) and on Win 7 and it is working fine for me, i.e. executables are generated and appear under Debug/ folder. Did you check if the files really missing on the filesystem (could be refresh problem in eclipse)? Is the problem accompanied with any exception in .metadata/.log? Are you using Internal or External builder?
It is working fine with External builder. It fails only with Internal builder. I found no exception in log file. It is not a refresh problem. If "Stop on first build error" is unchecked, the output is: 8<-------------------------------------------------------------- **** Rebuild of configuration Debug for project Hello **** **** Internal Builder is used for build **** gcc -O0 -g3 -Wall -c -fmessage-length=0 -o src\Hello.o ..\src\Hello.c gcc -o Hello.exe src\Hello.o gcc: src\Hello.o: No such file or directory gcc: no input files Build completed with errors Time consumed: 797 ms. --------------------------------------------------------------8< What I understand is: Compilation launch: OK (good command line) Compilation result: OK (no error messages) Link edition launch: OK (good command line) Link edition result: ERROR (file generated by first step has disapeared) Now let's go further. Create a file called gccWithDir.bat at the top level of the project, with the following content: 8<-------------------------------------------------------------- DIR /B /S C:\Cygwin\bin\GCC.EXE %* DIR /B /S --------------------------------------------------------------8< Set the Command field in the Tool Settings tab to "cmd /d /c ..\gccWithDir.bat", for compiler and linker. Now, the build output is: 8<-------------------------------------------------------------- **** Rebuild of configuration Debug for project Hello **** **** Internal Builder is used for build **** cmd /d /c C:\TEMP\eclipse\ws\Hello/gccWithDir.bat -O0 -g3 -Wall -c -fmessage-length=0 -o src\Hello.o ..\src\Hello.c C:\TEMP\eclipse\ws\Hello\Debug>DIR /B /S C:\TEMP\eclipse\ws\Hello\Debug\src C:\TEMP\eclipse\ws\Hello\Debug>C:\Cygwin\bin\GCC.EXE -O0 -g3 -Wall -c -fmessage-length=0 -o src\Hello.o ..\src\Hello.c C:\TEMP\eclipse\ws\Hello\Debug>DIR /B /S C:\TEMP\eclipse\ws\Hello\Debug\src C:\TEMP\eclipse\ws\Hello\Debug\src\Hello.o cmd /d /c C:\TEMP\eclipse\ws\Hello/gccWithDir.bat -o Hello.exe src\Hello.o C:\TEMP\eclipse\ws\Hello\Debug>DIR /B /S C:\TEMP\eclipse\ws\Hello\Debug\src C:\TEMP\eclipse\ws\Hello\Debug>C:\Cygwin\bin\GCC.EXE -o Hello.exe src\Hello.o GCC: src\Hello.o: No such file or directory GCC: no input files C:\TEMP\eclipse\ws\Hello\Debug>DIR /B /S C:\TEMP\eclipse\ws\Hello\Debug\src Build completed with errors Time consumed: 703 ms. --------------------------------------------------------------8< We can see that the Hello.o file is present at the end of compilation step, but has disapeared at the beginning of the linkage step. And between the two steps, only the Internal builder can have made something.
This could be related to the issue we have seen from time to time with full/clean builds inverting the order of the clean build and then the incremental build... i.e. sometimes the clean happens after the build, when it should happen first. That would cause the internal builder to delete the output files.