(glibc-2.0.7) c++ constructors and pthreads

[H.J. Lu]

> 
> 
> I have a crash case here for a program which has global c++
> constructors and links against linuxthreads, one of the c++
> constructors ends up calling malloc(), and this crashes because the
> pthread constructor has not run yet and malloc() wants to setup it's
> internal locks in the private area of the pthread_initial_thread.
> 
> This is deadly on machines such as Sparc which have to do
> INIT_THREAD_SELF to initialize a global register to point to the
> thread information block.
> 
> This looks rather nasty and I cannot think of a clean fix to make sure
> pthread's constructor runs early enough in a guarenteed manner.
> 

I don't think it is too hard to make sure that the pthread constructor
always runs first. I am thinking something adding

extern void _pthread_initialize ();
#pragma weak _pthread_initialize

	if (_pthread_initialize)
	   _pthread_initialize ();

somewhere and make sure it is called before _init (). Of course, we
have to change pthread_initialize also.


-- 
H.J. Lu (hjl@gnu.org)