SVN 1615-uni not handling .rc files correctly

[grunerite]

Wow, what a headache I just had.

WinXP
1.0RC2 (oct.24) and SVN-rev1615-uni


I could build an .exe with RC1, but the exact same project and settings cannot build in SVN-rev1615-uni. Rev1615 gives this error message on linking:

Code

mingw_gcc344\Release\Controls.o:Controls.cpp:(.text+0x0): multiple definition of `main'
mingw_gcc344\Release\Controls.o:Controls.cpp:(.text+0x0): first defined here

I was racking my brain because I thought the problem was my code (which has 2 "main") and libs:

Code

int main(int argc, char *argv[])
{
	Application* app = new ControlsApplication( argc, argv );


	Application::main();

	return 0;
}

You can imagine how many lib rebuilds I did thinking something was wrong with my lib build settings.

Anyway, it turns out I think it is related to resource file extensions. Here is the succesful exe build output with RC1 (note the two compiled files controls.o and controls.res, ok):

Code

Project   : Controls
Compiler  : GNU GCC Compiler (called directly)
Directory : C:\Dev\VCF\vcf\examples\Controls\
--------------------------------------------------------------------------------
Switching to target: Win32 Release
mingw32-g++.exe    -LC:\Dev\CodeBlocks\lib -o C:\Dev\VCF\vcf\examples\Controls\mingw_gcc344\Release\Controls.exe mingw_gcc344\Release\ControlsAbout.o mingw_gcc344\Release\ControlsApplication.o mingw_gcc344\Release\MainWindow.o mingw_gcc344\Release\Controls.o  mingw_gcc344\Release\Controls.res    -Wl,--enable-runtime-pseudo-reloc    -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32 ..\..\bin\libApplicationKitDLL_mingw_gcc344.a ..\..\bin\libGraphicsKitDLL_mingw_gcc344.a ..\..\bin\libFoundationKitDLL_mingw_gcc344.a  -mwindows
Info: resolving vtable for VCF::Rectby linking to __imp___ZTVN3VCF4RectE (auto-import)
Info: resolving vtable for VCF::StandardContainerby linking to __imp___ZTVN3VCF17StandardContainerE (auto-import)
Process terminated with status 0 (0 minutes, 1 seconds)
0 errors, 0 warnings

Now, with SVN-1615uni, the bad build looks like so (notice 2 controls.o and no controls.res):

Code

-------------- Build: Win32 Release in Controls ---------------
mingw32-g++.exe -LC:\Dev\MinGW344\lib  -o C:\Dev\VCF\vcf\examples\Controls\mingw_gcc344\Release\Controls.exe mingw_gcc344\Release\ControlsAbout.o mingw_gcc344\Release\ControlsApplication.o mingw_gcc344\Release\MainWindow.o mingw_gcc344\Release\Controls.o  mingw_gcc344\Release\Controls.o  -Wl,--enable-runtime-pseudo-reloc  -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -luuid -lodbc32 -lodbccp32 ..\..\bin\libApplicationKitDLL_mingw_gcc344.a ..\..\bin\libGraphicsKitDLL_mingw_gcc344.a ..\..\bin\libFoundationKitDLL_mingw_gcc344.a  -mwindows
Info: resolving vtable for VCF::Rectby linking to __imp___ZTVN3VCF4RectE (auto-import)
Info: resolving vtable for VCF::StandardContainerby linking to __imp___ZTVN3VCF17StandardContainerE (auto-import)
mingw_gcc344\Release\Controls.o:Controls.cpp:(.text+0x0): multiple definition of `main'
mingw_gcc344\Release\Controls.o:Controls.cpp:(.text+0x0): first defined here
collect2: ld returned 1 exit status
Process terminated with status 1 (0 minutes, 1 seconds)
0 errors, 0 warnings

So, it appears to be compiling controls.cpp twice and not controls.rc. Here are the lines from the .cbp file showing the 2 controls file:

Code

        </Build>
        <Unit filename="Controls.cpp">
            <Option compilerVar="CPP" />
            <Option target="Win32 Release" />
            <Option target="Win32 Debug" />
        </Unit>
        <Unit filename="Controls.rc">
            <Option compilerVar="WINDRES" />
            <Option objectName="Controls.res" />
            <Option target="Win32 Release" />
            <Option target="Win32 Debug" />
        </Unit>

Is this a bug (I think so) or something I'm doing wrong? I'll report this to sourceforge soon when I'm certain it is a bug and not something I'm doing wrong.
Grunerite

[thomas]

If I read this correctly, this is not a problem with the compiler but with the linker commandline.

controls.cpp is only compiled once, but controls.o is linked twice when controls.res should be used in once place. I can't tell if this is a bug or misconfiguration, though.

[grunerite]

I think it is a bug unless there is an option I'm missing. I changed the name of Controls.rc to Controls2.rc, and rebuilt. Controls2.rc now compiles to Controls2.o, so there is no duplicate Controls.o. All works fine then.

Any advice on how to deal with this? Is there an option somewhere to say Windres.exe compiled files should have extension .res instead of .o?

[grunerite]

If I read this correctly, this is not a problem with the compiler but with the linker commandline.

controls.cpp is only compiled once, but controls.o is linked twice when controls.res should be used in once place. I can't tell if this is a bug or misconfiguration, though.

Well, the problem is windrese.exe is producing an output file with .o extension, and not .res extension. As you see above from the project file, it is told to compile to a Controls.res file, but it does not. And for some reason, the linker tries to link in 2 Controls.o, and it grabs the same file twice (the one produced from Controls.cpp).

During compiling, here is the command line for compiling Controls.rc, and it does indeed say it is outputting a Controls.o, even though the project file tells it to output Controls.res

windres.exe -i Controls.rc -J rc -o mingw_gcc344\Release\Controls.o -O coff -IC:\Dev\CodeBlocks\include

[mandrav]

Code

1621  	/  	mandrav  	2 days  	* Fixed bug with generated object name for windows resources.

That's why you need to update to the latest revision, if using the SVN version, when you think you 've found a bug...

[grunerite]

Code

1621  	/  	mandrav  	2 days  	* Fixed bug with generated object name for windows resources.

That's why you need to update to the latest revision, if using the SVN version, when you think you 've found a bug...

Sorry    Will do next time. This project moves at a fast pace!