Re: Initialization of unused global variables from static libraries.
* Alf P. Steinbach:
* Milan Radovich:
Hello,
I have 2 files:
a.cc:
---------------------------------------
int main()
{
return 0;
}
---------------------------------------
b.cc:
---------------------------------------
#include <iostream>
bool foo()
{
std::cout << "foo" << std::endl;
return true;
}
const bool bar = foo();
---------------------------------------
If I compile the application like that:
g++ -c a.cc b.cc
g++ a.o b.o -o a
then when application is executed, it outputs a string "foo".
But if I create a static library from b.cc and then link application
with that library, like that:
g++ -c a.cc b.cc
ar rcs libb.a b.o
g++ -L. -lb a.o -o a2
then when application is ran, it doesn't print anything.
After I searched for the reason why this happens, I found that
when linking with static libraries, linker omits code which is not
reachable through any execution path.
The question is:
1) Is it a correct behaviour according to a Standard?
No, regardless of how the code is physically packaged.
?3.7.1/2 "If an object of static storage duration has initialization or
a destructor with side effects, it shall not be eliminated even if it
appears to be unused, except that a class object or its copy may be
eliminated as specified in 12.8".
?12.8 then talks about elimination of copy constructor calls, in
?12.8/15, which is not your case.
As it turned out by discussion with Pete Becker, I was wrong about this.
Hm, I can't even blame lack of coffee, even though I was a bit tired. Well,
that's enough. Good excuse! :-) Bad extra defense: now that some wool has been
removed I recall writing about this problem earlier, at length. Oh well.
The crucial insight is that only translation units that are somehow referenced
by code, need to be included in the final program, and that ?3.7.1 and the rest
of the standard only applies to code in the actually included TU's.
Translation unit [a.cc] is referenced & therefore included by virtue of
containing "main", but there's no reference to anything in [b.cc].
So, a simple fix is to reference something in [b.cc], e.g. a call of some dummy
function there.
Pitfall for the simple fix: the standard's ?3.6.2/3 supports deferring the
dynamic initialization of statics in a TU until the first call of a function or
reference of an object in the TU. This can play havoc with using e.g. a factory
where types have installed themselves via the dynamic initialization of statics
in their translation units, if the use of the factory occurs before the first
call of a function or reference of object in some self-registering type's TU.
2) Is there is a pattern which forces linker to add such a code to an
executable?
I'd try an object with a constructor.
I'd now instead try to reference something in the TU.
Cheers & hth.,
- Alf