will linker leave out unused symbols from binary?

[Sam Smith]

Hi,

I'm thinking about whether or not to build a general library on its own and
later link that lib with the main executable, or to build the main
executable with a subset of the relevant source files from that library.

If I choose to build the executable directly with only relevant source
files, I know I do not bloat the executable with symbols and functions that
are never used.

But I do not like to manage this kind of dependency! I'd much rather just
build a lib with all files that belongs to that module and later link
against that library when producing the exe. Separations of concern and easy
management of dependicies :-)

However, I'm not sure if this may lead to an undesired increase of the
executable's size (since unused symbols and functions may get linked in into
the executable). What is the story about this?

I know that this must be an implementation issue, i.e. it is up to the
linker to leave unused stuff out of the exe - but I hope that there is a
general answer :-)

Thanks in advance!

[John Harrison]

"Sam Smith" <sa*@smith.com> wrote in message
news:%m****************@nntpserver.swip.net...

Hi,

I'm thinking about whether or not to build a general library on its own and later link that lib with the main executable, or to build the main
executable with a subset of the relevant source files from that library.

If I choose to build the executable directly with only relevant source
files, I know I do not bloat the executable with symbols and functions that are never used.

But I do not like to manage this kind of dependency! I'd much rather just
build a lib with all files that belongs to that module and later link
against that library when producing the exe. Separations of concern and easy management of dependicies :-)

However, I'm not sure if this may lead to an undesired increase of the
executable's size (since unused symbols and functions may get linked in into the executable). What is the story about this?

I know that this must be an implementation issue, i.e. it is up to the
linker to leave unused stuff out of the exe - but I hope that there is a
general answer :-)

The general answer is that it is an implementation issue. Consult your
linker documentation. Maybe even do some experiments.

Incidentally this question has very little to do with C++ which is what this
group is supposed to be about.

john

[Victor Bazarov]

Sam Smith wrote:

I'm thinking about whether or not to build a general library on its own and
later link that lib with the main executable, or to build the main
executable with a subset of the relevant source files from that library.

If I choose to build the executable directly with only relevant source
files, I know I do not bloat the executable with symbols and functions that
are never used.

But I do not like to manage this kind of dependency! I'd much rather just
build a lib with all files that belongs to that module and later link
against that library when producing the exe. Separations of concern and easy
management of dependicies :-)

However, I'm not sure if this may lead to an undesired increase of the
executable's size (since unused symbols and functions may get linked in into
the executable). What is the story about this?

I know that this must be an implementation issue, i.e. it is up to the
linker to leave unused stuff out of the exe - but I hope that there is a
general answer :-)

There is no general answer, not in terms of Standard C++ language, anyway.
Linkers are OS-dependent, compiler-dependent, and differ from vendor to
vendor. Some are smarter, some are dumber. All we can tell you that you
are right to _want_ this, but there is no guarantee to get it.

V

[David Harmon]

On Tue, 28 Sep 2004 16:16:45 +0200 in comp.lang.c++, "Sam Smith"
<sa*@smith.com> wrote,

If I choose to build the executable directly with only relevant source
files, I know I do not bloat the executable with symbols and functions that
are never used.

A typical common behavior is that the linker will pull out of the
library any object file that is needed to satisfy a reference, and leave
out any object file that is completely unused, but it cannot split up
any object file and bring in part of it. For best results the library
must be built out of many small object files each containing the
smallest working subset of mutually dependent code and data.

Of course this is outside the scope of the C++ language and you must
read the fine manual of your particular implementation.

[Nils O. Selåsdal]

Sam Smith wrote:

Hi,

I'm thinking about whether or not to build a general library on its own and
later link that lib with the main executable, or to build the main
executable with a subset of the relevant source files from that library.

If I choose to build the executable directly with only relevant source
files, I know I do not bloat the executable with symbols and functions that
are never used.

But I do not like to manage this kind of dependency! I'd much rather just
build a lib with all files that belongs to that module and later link
against that library when producing the exe. Separations of concern and easy
management of dependicies :-)

However, I'm not sure if this may lead to an undesired increase of the
executable's size (since unused symbols and functions may get linked in into
the executable). What is the story about this?

I know that this must be an implementation issue, i.e. it is up to the
linker to leave unused stuff out of the exe - but I hope that there is a
general answer :-)

There is not.

On e.g. GNU/Linux, if you create a (static archive/library)
every object file as a whole is either included or not.
That is, if something is needed in a .o file, the whole .o
file is linked in, otherwise it is left out. This seems
rather common among other implmentations as well though.