The static library benefits

  • Thread starter Thread starter sealo
  • Start date Start date
S

sealo

Hello,
In VS2005, if APP A is using a static library B.lib, although there
are many objects contained in the B.lib, but App only use part of it,
will the compiler only adopted the part that the App actually need, or
bind all the objects of B.lib into the App?

App A --> B.lib
 
Hello,
In VS2005, if APP A is using a static library B.lib, although there
are many objects contained in the B.lib, but App only use part of it,
will the compiler only adopted the part that the App actually need, or
bind all the objects of B.lib into the App?

App A --> B.lib
Click to expand...

Later, I test it in the VS

App A --> B.lib --> C.lib

Then I call C.lib function in App A, it works.
It approve that, B.lib contain all the method of C.lib. But Whether
App A contain all the method of B and C.lib is unknown.
 
In VS2005, if APP A is using a static library B.lib, although there
are many objects contained in the B.lib, but App only use part of it,
will the compiler only adopted the part that the App actually need, or
bind all the objects of B.lib into the App?
Click to expand...

Only the used part is contained in the final application.
(it also depends how the lib is organized in modules).
 
Only the used part is contained in the final application.
(it also depends how the lib is organized in modules).
Click to expand...

The B.lib will include all the functions of C.lib, even there are no
app use B.lib. Right?
 
sealo said:
The B.lib will include all the functions of C.lib, even there are no
app use B.lib. Right?
Click to expand...

Sealo:

No. A .lib file is not linked. It is just a collection of .obj files. If
your A.exe references B.lib, abd B.lib references C.lib, then all the
..obj files of B.lib and C.lib will be available to the A.exe linker.
Only those that are actually used will be retained in the image.
 
David Wilkinson said:
Sealo:

No. A .lib file is not linked. It is just a collection of .obj files. If
Click to expand...

That's why it wouldn't contain only the functions of C needed by B. If you
pass C.lib to the lib command building B.lib, then C.lib will be included in
its entirety.
 
David said:
Sealo:

No. A .lib file is not linked. It is just a collection of .obj files.
If your A.exe references B.lib, abd B.lib references C.lib, then all
the .obj files of B.lib and C.lib will be available to the A.exe
linker. Only those that are actually used will be retained in the
image.
Click to expand...

One more detail - the linker normally can only choose to load a module (an
..obj file) or not from a library - so if that module contains 20 functions
and only 1 is referenced, all 20 will still be present in the linked image.
But, there's a compiler switch - /Gy ("separate functions for linker") which
will put each and every function into it's own section, allowing the linker
to include only those functions that are actually used. Compiling with /Gy
will make your .obj's and .lib's larger and will increase link time, but
will normally decrease final image size.

-cd
 
David Wilkinson said:
Hi Carl:

I didn't know that. I thought that by default the linker would whittle
away at the image so that nothing not needed was present.
Click to expand...

But the linker might not have the information on which global variables and
helper functions are used by which public functions...
 
Ben said:
That's why it wouldn't contain only the functions of C needed by B. If you
pass C.lib to the lib command building B.lib, then C.lib will be included in
its entirety.
Click to expand...

Hi Ben:

Oh yes, I misread sealo's post. He didn't say that B.lib would contain
only the stuff from C.lib that it needed; somehow I thought he did.
 
Carl said:
One more detail - the linker normally can only choose to load a module (an
.obj file) or not from a library - so if that module contains 20 functions
and only 1 is referenced, all 20 will still be present in the linked image.
But, there's a compiler switch - /Gy ("separate functions for linker") which
will put each and every function into it's own section, allowing the linker
to include only those functions that are actually used. Compiling with /Gy
will make your .obj's and .lib's larger and will increase link time, but
will normally decrease final image size.
Click to expand...

Hi Carl:

I didn't know that. I thought that by default the linker would whittle
away at the image so that nothing not needed was present.

Another thing learned.
 
David Wilkinson said:
Hi Ben:

Mmmm. The linker will sure complain if anything is missing, so why can't
it keep a list of things it has found not to be missing?
Click to expand...

oops, I meant to say file-scoped variables and helper functions.... which
would be resolved by the compiler and not appear in the link symbols.
 
Ben said:
But the linker might not have the information on which global variables and
helper functions are used by which public functions...
Click to expand...

Hi Ben:

Mmmm. The linker will sure complain if anything is missing, so why can't
it keep a list of things it has found not to be missing?

I dig myself a little deeper ...
 
Back
Top