Static library(.lib) v/s dynamic library(.dll) size confusion
Nithin
I have a static library(.lib) with some 234 files in it.When I build
it the size of the .lib is around 8MB.(just building the library not
attaching to any application)
When I build the same 234 files in a different project which is a
Dynamic link library(.dll) the size is around 2 MB.
My question is even though I have the same number of files in both
cases why is static library(.lib) size so large??I am working in some
embedded project so size is a major constraint
Best Regards,
Nithin
Nathan Mates
Nithin <nithin....@gmail.com> wrote:
>My question is even though I have the same number of files in both
>cases why is static library(.lib) size so large??I am working in some
>embedded project so size is a major constraint
Because when you choose to use the C Runtime (aka CRT) libraries in
a static configuration, then any functions you use from the C Runtime
libs (starting with basics like printf, and going up from there) must
be embedded in your .lib. That's the definition of static
linking. Dynamic linking to the CRT means that those functions from
the CRT are loaded from a shared .dll, so they don't need to be in the
.lib.
Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
Ulrich Eckhardt
Nathan already said that a statically vs a dynamically linked runtime makes
a difference.
Another possible point is that with a DLL, unused stuff can be discarded.
The required parts are DllMain(), all symbols marked with
declspec(dllexport) and those they depend on. In a static library, no such
selection is make. I'm not 100% sure that this is automatically discarded
though.
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
David Wilkinson
> In article <39b33070-4864-4695...@y28g2000prd.googlegroups.com>,
> Nithin <nithin....@gmail.com> wrote:
>> My question is even though I have the same number of files in both
>> cases why is static library(.lib) size so large??I am working in some
>> embedded project so size is a major constraint
>
> Because when you choose to use the C Runtime (aka CRT) libraries in
> a static configuration, then any functions you use from the C Runtime
> libs (starting with basics like printf, and going up from there) must
> be embedded in your .lib. That's the definition of static
> linking. Dynamic linking to the CRT means that those functions from
> the CRT are loaded from a shared .dll, so they don't need to be in the
> .lib.
OP is talking about a static .lib project versus a dynamic .dll project, not
about static versus dynamic linking of CRT. These, I think, are orthogonal issues.
To the OP: how are you linking to CRT in these projects?
--
David Wilkinson
Visual C++ MVP
Ulrich Eckhardt
> OP is talking about a static .lib project versus a dynamic .dll project,
> not about static versus dynamic linking of CRT. These, I think, are
> orthogonal issues.
They are, but is (or was) a statically linked CRT not the default for static
libraries under VS?
> To the OP: how are you linking to CRT in these projects?
Indeed, that's the question.
Scot Brennecke
If all the logical approaches already suggested don't pan out, there's
dumpbin to help look inside for details.
Tamas Demjen
> My question is even though I have the same number of files in both
> cases why is static library(.lib) size so large??
I'm not a compiler expert, and may be wrong about some of the specific
details, but here's my theory.
DLLs contains fully compiled and executable machine code, while obj/lib
files don't. The final addresses of functions and variables are not
always known until the end of the linking process, therefore a lot of
addresses have to be labeled. Instead of using 32-bit (or 64-bit)
addresses, lib files use fully qualified names, which include the
namespace, and even the types of all the function arguments. These
labels can easily be 20-200 bytes long. Think of map<string, string>::
iterator, for example -- that type name alone is several 100 bytes
long (when fully expanded), and lib files tend to contain 100s of copies
of those labels.
Although DLLs don't necessarily have to contain any labels, they almost
always do. Exported functions are usually named, not just indexed,
and RTTI requires each class' name is stored as a string. However, each
type and function only needs to be named once, whereas in a lib file,
every occurrence/reference is named independently. For example, every
function call potentially contains a label in the object file, and extra
debugging information may also be present, which is not in the DLL.
At the minimum you have to consider the .pdb file size, and treat it
like if it belonged to the DLL, if you want a fair comparison.
Finally, the lib could potentially contain unused functions and classes.
Consider the stblib, for example. Most apps don't use 100% of the
standard library. The linker can optimize unused functions away.
Static libraries were designed to be temporary files, like object files,
and C++ libs are not particularly portable, so you're not supposed to
distribute them anyway.
Tom