Toolkit Pro - VS10 creates bloated static libs

Print Page | Close Window

VS10 creates bloated static libs

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=16681
Printed Date: 21 June 2025 at 12:21am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: VS10 creates bloated static libs

Posted By: rconn
Subject: VS10 creates bloated static libs
Date Posted: 09 May 2010 at 4:54pm

Using 13.3.1 and VS2010.

I converted from 13.2.1 to 13.3.1 and switched to VS2010 at the same time. After rebuilding everything I found that my release .exe's had increased 50% in size.

I'm statically linking 13.3.1. Looking at the libs I see that the Codejock *SU.LIB file has increased 40-50% in size using VS2010 versus the same lib using VS2008 (and is nearly the size of the debug lib). The debug lib (*SUD.LIB) is roughly the same size as in VS2008.

I presume something is misconfigured in the VS2010 release properties.

Replies:

Posted By: eddiepaz
Date Posted: 10 May 2010 at 9:05am

I assume this has to do with VS 2010 creating bloated executables when statically compiling. A simple dialog application is now 1.6MB, and MS says it's because of the new features. <g>

http://connect.microsoft.com/VisualStudio/feedback/details/461441/mfc-static-lib-link-exe-size-too-large - http://connect.microsoft.com/VisualStudio/feedback/details/461441/mfc-static-lib-link-exe-size-too-large

Posted By: rconn
Date Posted: 10 May 2010 at 9:34am

That might be part of it, though the Codejock-supplied projects were also including debug info in the VS2010 release builds. When I took that option out, the Codejock libs dropped 30mb+ in size. That reduced my release build size significantly, though it was still bigger than VS2008 (presumably because of VS2010 & static linking).

Posted By: Smucker
Date Posted: 10 May 2010 at 12:26pm

I always include debug info in .LIBs, so that it gets propagated to the final .PDB and .MAP generated with the .EXE, making dumps readable. (I don't distribute the PDB or MAP.)

For a smaller EXE, you may want to turn on function-level linking (/Gy in the compiler), so that unreferenced code doesn't get in the EXE. I don't know of anything this breaks, unless you're doing some weird stuff with pointers to functions or methods. I do this for all projects.

That note from Microsoft seems rather odd; I wonder if the MFC libraries are being compiled /Gy, or if they're just doing something else wrong.

-------------
Product: Xtreme Toolkit Pro version 13.2 (Unicode, static build)

Platform: Windows 200x/XP/Vista/Win7 (32/64 bit)

Language: Visual C++ 9.0 (Studio 2008)

Posted By: rconn
Date Posted: 10 May 2010 at 7:19pm

I always use /Gy. It doesn't help in this case.

Posted By: Smucker
Date Posted: 10 May 2010 at 9:19pm

I wonder if the MFC lib is compiled with /Gy (or if there's some reason it can't be).

-------------
Product: Xtreme Toolkit Pro version 13.2 (Unicode, static build)

Platform: Windows 200x/XP/Vista/Win7 (32/64 bit)

Language: Visual C++ 9.0 (Studio 2008)

Posted By: znakeeye
Date Posted: 11 May 2010 at 9:50am

Are you using VS2008 or VS2008 SP1? My guess is that you get the same bloat in VS2008 SP1.

-------------
PokerMemento - http://www.pokermemento.com/

Posted By: rconn
Date Posted: 11 May 2010 at 6:43pm

Nope, no problem with VS2008 SP1.

Posted By: znakeeye
Date Posted: 12 May 2010 at 4:02am

If you're linking statically with MFC, then you will get bloat in VS 2008 SP1 and VS 2010. This is due to the ribbon graphics included in the new versions of MFC.

-------------
PokerMemento - http://www.pokermemento.com/

Posted By: znakeeye
Date Posted: 12 May 2010 at 4:30am

Also, make sure you have NO references to afxcontrolbars.h or CWinAppEx.

-------------
PokerMemento - http://www.pokermemento.com/