Release of a static .LIB in the VS 2005

[Victor]

Hi everybody !

Could anybody shed some light into the following paradox :

I am creating a static library under VS 2005 VC++ Win32 using MFC. If
compiled right after creating by a wizard, a release version of the LIB
shows the size of almost 2 MB - without any contents of mine ! The
debug version is less then a tenth of it at that...

Is it a problem of some wrong project settings or is it a bug? Or
maybe, this is OK so, then what sense can it have ?

Regards
Victor

 

[Bruno van Dooren]

could you check that your release version is linked dynamiclly against MFC?
if it is linked against the static MFC libraries, that could account for the
difference.

configuration properties -> general ->use of MFC set to 'MFC in a shared
dll'

kind regards,
Bruno.

 

[Victor]

Thank you, Bruno

however, this option has been always selected in both debug and release
versions... exactly the way you say.
So, the reason must be elsewhere.

Victor

 

[Holger Grund]

Could anybody shed some light into the following paradox :

I am creating a static library under VS 2005 VC++ Win32 using MFC. If
compiled right after creating by a wizard, a release version of the LIB
shows the size of almost 2 MB - without any contents of mine ! The
debug version is less then a tenth of it at that...

Is it a problem of some wrong project settings or is it a bug? Or
maybe, this is OK so, then what sense can it have ?

You probably build with /GL & /LTCG in release. The compiler will
save an intermediate representation instead of generated code in that
case. The switch is under General (not C/C++ !)->WPO.

You can run dumpbin on your object files. If it says anonymous object
you have an LTCG object.

Lib size is a poor indicator for actual code size. You really need to
take a look at final linked image file.

-hg

 

[Victor]

I have checked the switch General/WPO (if I understood it correctly, it
stays for Whole Programm Optimization). Indeed, there were differencies
between the both Debug and Release versions : Debug had 'No Whole
Programm Optimization', during Release had 'Use Link Time Code
Generation'.

Well, I changed the switch for Release to 'No WPO' either. This has
brought an immediate effect : the size of the .LIB file reduced to a
fifth ! (BTW - I meant always the real size of final linked file). It
is still fast 500 MB, nevertheless!

Is it not a bit exaggerated for an empty project? Are there any other
switches I should check?

Victor

 

[Holger Grund]

I have checked the switch General/WPO (if I understood it correctly, it
stays for Whole Programm Optimization). Indeed, there were differencies
between the both Debug and Release versions : Debug had 'No Whole
Programm Optimization', during Release had 'Use Link Time Code
Generation'.

Yes, I'm sorry WPO = Whole Program Optimization. In this case
the actual code generation is deferred to link time. It therefore enables
the compiler to do optimizations that require information from all
translation units (for instance inlining a function that is implemented
in another .cpp file)

WPO can reduce the code size (for the final EXE or DLL), but
modern desktop compilers are probably more geared for faster
code.

Well, I changed the switch for Release to 'No WPO' either. This has
brought an immediate effect : the size of the .LIB file reduced to a
fifth ! (BTW - I meant always the real size of final linked file). It

Just to make sure. The .lib file is _not_ the final linked file. Only
EXE or DLL are.

is still fast 500 MB, nevertheless!

I take it you mean KB. Otherwise it would really be a lot.

I'm not sure however, you fully understand what's going on.
The .lib is just a container for all object files (much like a tar
file or a zip file without the compression).

You said, you didn't add any source file yourself. So you'll
probably only have the MFC include files. These contain
inline functions and global data. Inline functions are only
emitted if referenced. So you'll probably only have data
symbols.

When you link your EXE or DLL the linker automatically
includes all object file you give on the command line.
Object files from .libs, however, will only be pulled in
if they contain a definition of a symbol that is referenced
by your code. That is, if you create a "Hello World" project
it doesn't matter if you link with a 100MB .lib or not - so long
as no symbols of the library are referenced.

Things get a bit more complicated with C++ code (which
uses COMDAT sections).

If you want a small image, make sure you build your lib
(or actually all of your code) with /Gy and link with /OPT:REF.

Again, only the size of your EXE or DLL is relevant.

-hg

 

[Victor]

Thank you Holger,

of course, I meant really 500 KB, not MB !..

Well, the size of my finally linked file (now I mean the target .EXE !
) is quite ordinary and makes me no trouble...

As I moved rather recently from the VC++ 6.0 to the VS 2005, only the
size of the .LIB made me wonder... When I created something like this
in 6.0, the LIB size was normally about 20 KB...

Surely, I can live with this situation as well. Pity about the disc
space only...

Victor

 

[Holger Grund]

Well, the size of my finally linked file (now I mean the target .EXE !
) is quite ordinary and makes me no trouble...

As I moved rather recently from the VC++ 6.0 to the VS 2005, only the
size of the .LIB made me wonder... When I created something like this
in 6.0, the LIB size was normally about 20 KB...

You probably didn't build with debug info in VC 6 (it was off by
default in the wizard IIRC). You can try to turn off /Zi (BTW: You
can always look these up in MSDN Library in the index and there's
a description where you can find the corresponding setting in the
IDE).

That being said, I strongly believe that the improved debug
experience by far outweighes the disk size ;-)

Surely, I can live with this situation as well. Pity about the disc
space only...

-hg