A difference between debug build with gcc and vc++

[miwarre]

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

[miwarre]

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:

<?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>

<?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>

To copy to clipboard, switch view to plain text mode 

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

[piotr.dobrogost]

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.

[piotr.dobrogost]

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?

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.

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.