A difference between debug build with gcc and vc++

Printable View

19th July 2009, 12:18
piotr.dobrogost

A difference between debug build with gcc and vc++

I'm building using both gcc and vc++.
When building formextractor example in debug mode gcc executable is 1 114 050 bytes and vc++ one is 75 776 bytes. When running, gcc executable runs ok but vc++ one gives error about not being able to find msvcr90d.dll file. It looks like gcc links with this statically whereas vc++ links dynamically.

How can I configure both builds in creator to have the same behavior in respect to linking to run-time libraries?
19th July 2009, 15:32
tjm

Re: A difference between debug build with gcc and vc++

If your static libraries are not kept in the same directory as your dynamic libraries, modify your project file LIBS variable with -L and -l

win32 {
LIBS += -LC:\path\to\lib\dir -llibname
} else {
LIBS += -L/path/to/lib/dir -llibname
}
19th July 2009, 16:57
piotr.dobrogost

Re: A difference between debug build with gcc and vc++

I think it has nothing to do with neither -L nor -l parameter. If it was something wrong with these two parameters then I couldn't have compiled project in the first place. Don't you think?

Quote:

Originally Posted by tjm

(...)modify your project file LIBS variable with -L and -l

Can I do it from within creator?
19th July 2009, 21:02
wysota

Re: A difference between debug build with gcc and vc++

Can you show us some of the compiler commands being ran? Especially the linking part (but one example of object compilation is also needed).

Re: A difference between debug build with gcc and vc++

Quote:

Originally Posted by wysota

Can you show us some of the compiler commands being ran? Especially the linking part (but one example of object compilation is also needed).

Code:

Running build steps for project formextractor...
Configuration unchanged, skipping QMake step.
Starting: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/BIN/nmake.exe 
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" -f Makefile.Debug
c:\Qt\4.5.2-vc\bin\uic.exe ..\formextractor.ui -o ui_formextractor.h
C:\Qt\4.5.2-vc\bin\moc.exe -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\4.5.2-vc\include\QtCore" -I"c:\Qt\4.5.2-vc\include\QtGui" -I"c:\Qt\4.5.2-vc\include\QtWebKit" -I"c:\Qt\4.5.2-vc\include" -I"c:\Qt\4.5.2-vc\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-vc\mkspecs\win32-msvc2008" -D_MSC_VER=1500 -DWIN32 ..\formextractor.h -o debug\moc_formextractor.cpp
 
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
 
 
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
 
C:\Qt\4.5.2-vc\bin\moc.exe -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\4.5.2-vc\include\QtCore" -I"c:\Qt\4.5.2-vc\include\QtGui" -I"c:\Qt\4.5.2-vc\include\QtWebKit" -I"c:\Qt\4.5.2-vc\include" -I"c:\Qt\4.5.2-vc\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-vc\mkspecs\win32-msvc2008" -D_MSC_VER=1500 -DWIN32 ..\mainwindow.h -o debug\moc_mainwindow.cpp
c:\Qt\4.5.2-vc\bin\rcc.exe -name formextractor ..\formextractor.qrc -o debug\qrc_formextractor.cpp
cl -c -nologo -Zm200 -Zc:wchar_t- -Zi -MDd -GR -EHsc -W3 -w34100 -w34189 -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\4.5.2-vc\include\QtCore" -I"c:\Qt\4.5.2-vc\include\QtGui" -I"c:\Qt\4.5.2-vc\include\QtWebKit" -I"c:\Qt\4.5.2-vc\include" -I"c:\Qt\4.5.2-vc\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-vc\mkspecs\win32-msvc2008" -Fodebug\ @.\nm6F60.tmp
main.cpp
formextractor.cpp
mainwindow.cpp
Generating Code...
cl -c -nologo -Zm200 -Zc:wchar_t- -Zi -MDd -GR -EHsc -W3 -w34100 -w34189 -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\4.5.2-vc\include\QtCore" -I"c:\Qt\4.5.2-vc\include\QtGui" -I"c:\Qt\4.5.2-vc\include\QtWebKit" -I"c:\Qt\4.5.2-vc\include" -I"c:\Qt\4.5.2-vc\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-vc\mkspecs\win32-msvc2008" -Fodebug\ @.\nm85A9.tmp
moc_formextractor.cpp
moc_mainwindow.cpp
qrc_formextractor.cpp
Generating Code...
link /LIBPATH:"c:\Qt\4.5.2-vc\lib" /NOLOGO /DEBUG /MANIFEST /MANIFESTFILE:"debug\formExtractor.intermediate.manifest" /SUBSYSTEM:WINDOWS "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /OUT:debug\formExtractor.exe @.\nm91BF.tmp
mt.exe -nologo -manifest "debug\formExtractor.intermediate.manifest" -outputresource:debug\formExtractor.exe;1
'mt.exe' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'mt.exe' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop.
Exited with code 2.
Error while building project formextractor
When executing build step 'Make'

That's strange but when I hit a build button for the second time I don't get above error and the build succeeds...

Code:

Running build steps for project formextractor...
Configuration unchanged, skipping QMake step.
Starting: C:/Program Files (x86)/Microsoft Visual Studio 9.0/VC/BIN/nmake.exe 
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\BIN\nmake.exe" -f Makefile.Debug
 
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
 
 
Microsoft (R) Program Maintenance Utility Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
 
Exited with code 0.

I think my problem is due to this error with mt.exe which is used to embed information about used libraries from manifest file (which is indeed generated as you can see in compiler's output) into the executable...

When I'm inspecting the executable with Dependency Walker I see that Qt uses other version of msvcr90d.dll than the one in the manifest.
Why during compilation of qt itself a different version of crt library was linked than the one that gets linked during compilation of an example in creator?

The most strange thing is that both versions of these dlls are present in the c:\windows\winsxs folder...

Any ideas?

19th July 2009, 22:00
wysota

Re: A difference between debug build with gcc and vc++

I think you should direct those questions to Microsoft, not to us :)

I can only confirm the above built is dynamic. If you show us the respective lines from gcc, I'll be able to say what causes the size difference.

Re: A difference between debug build with gcc and vc++

Output of gcc as requested.

Code:

Running build steps for project formextractor...
Starting: C:/qt/4.5.2-gcc4/bin/qmake.exe D:/projects/qt-test/formextractor.pro -spec C:/Qt/4.5.2-gcc4/mkspecs/win32-g++ -r 
Exited with code 0.
Starting: C:/mingw/4.4.0/bin/mingw32-make.exe -w 
mingw32-make: Entering directory `D:/projects/qt-test/gcc'
C:/mingw/4.4.0/bin/mingw32-make -f Makefile.Debug
mingw32-make[1]: Entering directory `D:/projects/qt-test/gcc'
c:\Qt\4.5.2-gcc4\bin\uic.exe ..\formextractor.ui -o ui_formextractor.h
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -o debug\main.o ..\main.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -o debug\formextractor.o ..\formextractor.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -o debug\mainwindow.o ..\mainwindow.cpp
C:/Qt/4.5.2-gcc4/bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -D__GNUC__ -DWIN32 ..\formextractor.h -o debug\moc_formextractor.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -o debug\moc_formextractor.o debug\moc_formextractor.cpp
C:/Qt/4.5.2-gcc4/bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -D__GNUC__ -DWIN32 ..\mainwindow.h -o debug\moc_mainwindow.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -o debug\moc_mainwindow.o debug\moc_mainwindow.cpp
c:\Qt\4.5.2-gcc4\bin\rcc.exe -name formextractor ..\formextractor.qrc -o debug\qrc_formextractor.cpp
g++ -c -g -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\Qt\4.5.2-gcc4\include\QtCore" -I"c:\Qt\4.5.2-gcc4\include\QtGui" -I"c:\Qt\4.5.2-gcc4\include\QtWebKit" -I"c:\Qt\4.5.2-gcc4\include" -I"c:\Qt\4.5.2-gcc4\include\ActiveQt" -I"debug" -I"." -I"..\..\qt-test" -I"." -I"c:\Qt\4.5.2-gcc4\mkspecs\win32-g++" -o debug\qrc_formextractor.o debug\qrc_formextractor.cpp
g++ -enable-stdcall-fixup -Wl,-enable-auto-import -Wl,-enable-runtime-pseudo-reloc -mthreads -Wl -Wl,-subsystem,windows -o debug\formExtractor.exe debug/main.o debug/formextractor.o debug/mainwindow.o debug/moc_formextractor.o debug/moc_mainwindow.o debug/qrc_formextractor.o -L"c:\Qt\4.5.2-gcc4\lib" -lmingw32 -lqtmaind -lQtWebKitd4 -lQtGuid4 -lQtCored4
mingw32-make[1]: Leaving directory `D:/projects/qt-test/gcc'
mingw32-make: Leaving directory `D:/projects/qt-test/gcc'
Exited with code 0.

19th July 2009, 23:21
wysota

Re: A difference between debug build with gcc and vc++

It's also dynamic. It's built in debug mode meaning that you have lots of symbol definitions included which bloats the code. The VC build was probably a release build (despite being built into debug directory), there is no chance a debug mode application that actually does something useful can have 75kB.
20th July 2009, 23:11
miwarre

Re: A difference between debug build with gcc and vc++

Quote:

Originally Posted by piotr.dobrogost

I'm building using both gcc and vc++.
When building formextractor example in debug mode gcc executable is 1 114 050 bytes and vc++ one is 75 776 bytes. When running, gcc executable runs ok but vc++ one gives error about not being able to find msvcr90d.dll file. It looks like gcc links with this statically whereas vc++ links dynamically.

How can I configure both builds in creator to have the same behavior in respect to linking to run-time libraries?

Hi,

Possibly it is not related to libraries. By default, vc++ does NOT include debug info in the executable but in an external <appname>.pdb file. This probably accounts for (the major part of) the difference in size.

The error about msvcr90.dll is probably another matter; I may be wrong, but I don't think that gcc needs this library at all; that's why it does not complain. On the other hand, vc++ does need it and you may not have it in your path.

The compiler option for statically linking the runtime library is /MT (/MTd for debug version), while the option for using DLL is /MD (/MDd for debug version).

Hope it helps.

Miwarre
21st July 2009, 08:08
miwarre

Re: A difference between debug build with gcc and vc++
Hi,

A second thought: the issue with msvcr DLL may (MAY) be due to a Side-by-side (SxS) issue.

You are probably familiar with SxS: it is a way MS devised to allow multiple versions of the same DLL to co-exist and the app (or the system) to choose the best match. Many (me included) think it is not worth the hassle, but it is there and we have to cope with it.

To let the system know about app's preferences about SxS-ed DLL's, the app needs to include a "manifest".

Now, msvcrXX.dll are SzS-ed DLL's and you had an error with the mt.exe tool, which is precisely the tool embedding a manifest in the app (the error seems to be intermittent, but it is a hint of possible mis-configuration anyway).

If you have a hex editor, look in the app .exe file for the string "manifestVersion"; if the app is manifest-ed correctly you should locate a text chunk like this:
Code:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> <security> <requestedPrivileges> <requestedExecutionLevel level='asInvoker' uiAccess='false' /> </requestedPrivileges> </security> </trustInfo> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> [possibly most <dependency>...</dependency> tags following] </assembly>
If there is no embedded manifest in the app, or the manifest does not reference the 'right' SxS (which the 'right SxS is, it is not always clear), your app will not find the DLL, no matter of PATH's and other settings.

I have noticed that sometime mt.exe does not do the right job and embeds an empty manifest; often by re-running it, things go better...

Just in case: the SxS-ed DLL's reside in the "<WindowsMainFolder>\WinSxS" folder; each has its own sub-folder (looking like "\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0 .21022.8_x-ww_597c3456\"); each also needs some registry settings (simply adding the sub-folder is not enough) and I never understood which.

If all of this simply looks like a mess... I agree with you.

Ciao,

Miwarre
21st July 2009, 09:37
piotr.dobrogost

Re: A difference between debug build with gcc and vc++

Quote:

Originally Posted by miwarre

Possibly it is not related to libraries. By default, vc++ does NOT include debug info in the executable but in an external <appname>.pdb file. This probably accounts for (the major part of) the difference in size.

I agree. There is <appname>.pdb file of 2M size.
The strange thing is there's no DEBUG defined when calling cl from the makefile.
VC++ can generate debug symbols even in release mode (http://stackoverflow.com/questions/218226).
I'm afraid this might be the case.
What do you think?

Quote:

Originally Posted by miwarre

The error about msvcr90.dll is probably another matter; I may be wrong, but I don't think that gcc needs this library at all; that's why it does not complain. On the other hand, vc++ does need it and you may not have it in your path.

I think every executable that uses dynamic crt needs some version of msvc... library.
I checked both versions for dynamic libraries dependencies with Dependency Walker. Here are the results

gcc version:

KERNEL32.DLL, MINGWM10.DLL, MSVCRT.DLL, MSVCRT.DLL, QTCORED4.DLL, QTGUID4.DLL, QTWEBKITD4.DLL

vc version:

KERNEL32.DLL, MSVCR90D.DLL, QTCORED4.DLL, QTGUID4.DLL, QTWEBKITD4.DLL

When I enable showing paths in DW it finds
MSVCRT.DLL file (in gcc case) in
c:\windows\syswow64\MSVCRT.DLL (I'm running Vista x64 so that's why there's syswow64 subfolder here)
and it finds MSVCR90D.DLL file (in case of vc) in
c:\windows\winsxs\x86_microsoft.vc90.debugcrt_1fc8 b3b9a1e18e3b_9.0.30729.1_none_bb1f6aa1308c35eb\MSV CR90D.DLL

I think msvcrt.dll is a kind of interface to specific version of msvc* crt library that happens to be installed in the system.
It's thought as a single entry point for all applications using msvc* crt libraries so that they don't have to worry about ensuring the specific version of dynamic crt is isntalled in the system.

Quote:

Originally Posted by miwarre

The compiler option for statically linking the runtime library is /MT (/MTd for debug version), while the option for using DLL is /MD (/MDd for debug version).

I know this but thanks for stating this for completeness.
21st July 2009, 09:43
piotr.dobrogost

Re: A difference between debug build with gcc and vc++

Quote:

Originally Posted by miwarre

A second thought: the issue with msvcr DLL may (MAY) be due to a Side-by-side (SxS) issue.

You are right. You can find whole story here.
30th July 2009, 12:09
ktk

Re: A difference between debug build with gcc and vc++

Quote:

Originally Posted by piotr.dobrogost

[CODE]Running build steps for project formextractor... {...}

Any ideas?

This usually happens when you have certain virus scanners 'active'. The linker writes the exe, Windows blatantly lies that writing it was successful
while in practice it was held by a malware scanner. Before that finished,
mt.exe is called, does not find the fresh exe, and bails out.

In the second try, the virus scanner finished in the mean time, and the exe has been written to disk, and mt.exe is happily embedding

There is not much you can do about that given that choice of operating system.