Re: [Fink-devel] lifetime of static variables

[David F. <fa...@cs...>]

Hi,

	I've also encountered the same problems with static initializers
not being called on Mac OS X, where the same code on compiles and
runes fine on every other platform.

> > I'm in the middle of updating my quantlib package and the test suite
> > is producing a failure that doesn't occur on any other platform.
> > Basically are there any known issues with the lifetime of static
> > variables with the november gcc update?

	The November update didn't fix it for me either.

> Mac OS X has always had issues with static variables in C++. Some
> programs depend on all static variables being init'ed on startup, but
> on OS X they are only init'ed when the module (.o) is actually used.
> This is a problem if a module's being used depends on its initializers,
> ie:
>
> static int Foo::ID = Bar.registerForUse(FooFactory());
>
> If this is the problem you're seeing, there's a fix (basically link the
> .o's together into one module, then link that into the lib, I think KDE
> still uses this fix). If it's something else, try giving more details
> and we'll see what can be done.

	I've been using patterns like the code above in my own traits
classes with static members.  I've found that linking all the object files
into one (via libtool convenience library) wasn't sufficient to force the
linker to link in the modules' static initializers.  I the problem I was
observing was that the linker didn't infer that certain modules were used
when in fact, they were.  (Is there some call-graph analysis gone wrong?)
I coerced linking by inserting some lines of code to call certain methods
(in a if (0) { } fashion) in my "top" main module, and that solved
the problem.  (My top module makes use of every other module.)  Not the
greatest fix, but a sufficient workaround, until I know better.

	I'd much rather learn about the internals of the linker to
understand where and why the ball is dropped...


David Fang
fangism at users dot sourceforge dot net