rvyas <rishabh.a.vyas@xxxxxxxxx> writes: >> As far as I know, that should work. However, if your program uses >> dlopen, then gcc needs the __cxa_atexit function to destroy globals in >> the right order. > > Thanks Ian. How do I figure out if my program uses dlopen and is there a way > around that? I'm not sure how to answer the question of whether your program uses dlopen. I assume that the obvious answer of grepping the source code doesn't work for some reason. If you have a dynamically linked executable you could run readelf -r and look for dlopen. > Also, I have attached a simple piece of code which replicates the problem. > While built/run on solaris/gcc it gives the following output: > > Function static 1 constructor called > Function static 2 constructor called > Global static 1 constructor called > Global static 2 constructor called > Function static 2 destructor called > Function static 1 destructor called > Global static 2 destructor called > Global static 1 destructor called > > The function statics are both created and destroyed before global statics > which is incorrect. > > > http://old.nabble.com/file/p30238350/gcc-statics.cpp gcc-statics.cpp OK, in that case the dlopen thing is a red herring. Sorry about that. I was able to recreate the problem using -fno-use-cxa-atexit. The problem is that without __cxa_atexit, there are two different mechanisms for destructors. Static destructors are run via atexit. Global destructors are run via .ctors/.dtors. This is so that dlclose will correctly destroy global variables, acknowledging that the program gets the wrong results for function statics. Your code shows that the program gets the wrong results for function statics even if dlclose is not called. In the absence of __cxa_atexit, it seems like the choices are: 1) get correct ordering for destruction of globals and function statics at the cost of not destroying globals when dlclose is called; 2) destroy globals when dlclose is called at the cost of incorrect ordering for destruction of globals and function statics. I don't see any obvious fix for this issue that does not require the cooperation of the system library, because it is the system library which handles dlclose and exit. Ian
