Re: [BUG] ld behavior varies for C++ static initializer depending on .a or .o input

[Alexandre Oliva <aoliva@redhat.com>]

On Apr 12, 2003, Hal Black <black@ieee.org> wrote:

>> That would mean that every static initializer in a .a file would be
>> brought in

> Yes, as desired.

Maybe in your specific application.  But think of the Standard C++
library.  It may contain hundreds, if not thousands, of global
initializers, that are of no use for most programs that don't happen
to use the particular feature that depend on some of these
initializers.  Bringing them in just because you would like it to be
so is not exactly a reasonable proposition.

> If you don't think this is the proper usage, what is your
> interpretation of the meaning of having a static intializer (or items
> with static storage duration in general) in a library?

No different from having it in an object file: if the object file is
linked in, the static initializer is run.  The difference is that
object files listed in the command line are always linked in, whereas
those in a static library get linked in only if they would resolve
some symbol the linker is looking for.

> My claim is that if it has a static initializer, it is required.

If we implemented this mis-feature, you'll come back tomorrow and
complain about the bloat from all these modules being linked in that
are not needed for your program to run, and the answer will be that
they do contain static initializers so, per your request, they have to
be brought in.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer