RE: bug with initialisation of global variables in a library (C++, gcc 2.95.2)

["Kris Thielemans" <kris dot thielemans at ic dot ac dot uk>]

Dear Fergus,

thanks a lot for the clear explanation.

I wonder if I can ask you some questions then on how to solve my problem. I
guess this doesn't really belong on the gcc mailing list, but more in a
general C++ forum. I'd be happy to transfer the discussion to say the C++
news group.

I'm not familiar with shared libraries (can anyone point me to some doc?)
but I presume they are OS dependent, which is a major problem for our
project. For one thing, I think that on Windows, DLL's have problems with
initialisation of static variables as well. So, I'm not very eager to go
this route.

Let me describe what we're trying to do. I have a hierarchy where all
children register themselves in a list (kept by the root of the hierarchy).
At run-time, the user can then say which of the children (s)he actually
wants to use. (In more or less standard jargon, each child has a factory,
and I keep a FactoryRegistry somewhere).

The intention is that the registration in the list of factories happens
automatically: each child will have a .o file. As soon as you link with it,
it should add the child to the registry. I use a well-known trick for this
by having a RegisterIt class with a constructor that will add a factory to
the registry. So, the only thing I have to do is to have a (static) variable
of type RegisterIt somewhere in the child's .cxx.

Hopefully you can now see why I had the problem I mentioned. Indeed, nowhere
in the .cpp, .h files, any of the children gets explicitly mentioned (except
of course in the child's own files).

The only alternative to shared libraries I now see to solve my problem is to
have somewhere in a .cpp file, a list of all possible children in some form.
Either as (a) global variables again, I then have to link with that .o file
explicitly (i.e. not in a library), or (b) in function which I'd have to
call in main().
I severely dislike this solution, as it means maintaining a file with all
possible children (and I'll have different hierarchies which use the same
philosophy).

Or is there another solution?

Thanks again,
and feel free to tell me I should ask this question somewhere else.

Kris Thielemans
(kris.thielemans@ic.ac.uk)
Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

Phone on :   +44 (020)8383 3731
FAX on :     +44 (020)8383 2029

web site address:
http://www.irsl.org/~kris

>
>
> On 26-Apr-2001, Kris Thielemans <kris.thielemans@ic.ac.uk> wrote:
> > I have a global variable in a stand-alone .cpp file (the
> variable is static
> > but doesn't need to be to reproduce the bug). Initialisation of this
> > variable should occur by calling a constructor. (This should
> happen before
> > the main function is started).
> >
> > However, this works only when I link with the corresponding .o
> file. If I
> > put the .o file in a library first (using ar), the constructors are NOT
> > called anymore.
>
> That's because the .o file is not being linked into your program.
>
> If you put an object file in a (static) library, and link to the
> library, then that object file will only be linked into your program if
> it is referenced.  This is a feature, not a bug ;-)
> If, as in your example, the object file only defines symbols with
> internal linkage (e.g. global variables declared `static'), then there
> is no way that it can be referenced.
>
> One way to avoid this problem is to use shared libraries rather
> than static libraries.
>