Re: Does -gc-section (garbage collection) works only with staticlinking ?

[Nick Clifton <nickc at redhat dot com>]

Hi Valery,

> However why only destructors and constructors? This is not perfect world (I
> mean not all of the programmers are guru) and not all classes has such high
> cohesion to have no "unneeded" function members :)

Well OK, other function-like things can also be eliminated by the 
linker.  I was trying not to get bogged down in the nitty gritty, 
especially since what is and is not eliminated can vary from target to 
target.

> > With static linking all of the references to symbols are resolved at
> > link-time and so the linker has the opportunity to detect and eliminate
> > unused functions.  (It needs assistance from the compiler in order to do
> > this, since the linker has no knowledge of flow control or program
> > semantics).  With dynamically linked code, some of the symbol references
> > are left unresolved until run-time and so the linker cannot know whether
> > a particular function is unreachable.  Hence it cannot eliminate anything.

> I didn't understand that fully. How the dynamic library code can depend on
> functions inside user (my) program if the program doesn't export any symbols
> (entry points) ?  I suppose when I do not export any entry points, my code
> can only call library functions and the library code cannot call ANY
> function within my program... So what is the problem to resolve the flow
> control ?

Your code could call a dynamic library function and pass to that 
function a pointer to another function inside your application.  This 
second function does not have to be exported, since it is your code that 
computes its address, but nevertheless the function can be accessed from 
outside of your code.  Think of the atexit() function supported by the C 
library as an example of this.

Cheers
  Nick