The static library benefits

[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

 

[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

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.

 

[Mihai N.]

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?

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

 

[sealo]

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

The B.lib will include all the functions of C.lib, even there are no
app use B.lib. Right?

 

[David Wilkinson]

The B.lib will include all the functions of C.lib, even there are no
app use B.lib. Right?

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.

 

[Ben Voigt [C++ MVP]]

Sealo:

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

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.

 

[Carl Daniel [VC++ MVP]]

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.

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

 

[Ben Voigt [C++ MVP]]

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.

But the linker might not have the information on which global variables and
helper functions are used by which public functions...

 

[David Wilkinson]

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.

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.

 

[David Wilkinson]

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.

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.

 

[Ben Voigt [C++ MVP]]

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?

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.

 

[David Wilkinson]

But the linker might not have the information on which global variables and
helper functions are used by which public functions...

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