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:

> I'm not an expert on g++ symbols, but I'm assuming the static
> intializer of the sort I'm talking about is is named
> __static_initialization_and_detruction.* because that's what nm
> reports for my test program.

Watch out for .ctor, .init or .init_array sections as well.

> I just hadn't heard any valid reasons against having it be as I
> describe, and it seems like the correct interpretation of the spec.

I disagree.  The compiler, which is the entity that deals with
translation units, isn't dropping any initializers, just like mandated
by the spec.  Now, by the Standard, a program is one or more
translation units linked together [basic.link], and that's it.
Nowhere does it get into details of what a linker is, nevermind how
static archives should behave, since this is all far beyond the scope
of the C++ Standard.

Your point that archives should be scanned for initializers would be
perfectly reasonable, except for the bloat one wouldn't be able to
avoid, but, like Ian says, this is not the way linkers have dealt with
archives in the past and, barring a strong reason to change, they
should change.  Standard compliance is not such a reason, because the
nowhere does the standard determine how to select the translation
units that go into a program.  

> Based on an earlier portion of your reply, I am taking your
> interpretation to mean that a static initializer in a library is only
> called when something references an instance of its class or members,
> but not otherwise.  I don't believe this is a valid view from reading
> the C++ spec.

My interpretation is that a static initializer in a translation unit
is only executed if the translation unit makes it to the program.  The
point under debate is whether the translation unit must make it to the
program in spite of not being referenced by any other translation unit
listed in the program.  If you have such requirements, using an
archive is the wrong approach: you want to list the object files
instead.

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