When creating constructor functions (at least within a shared library, not sure about within a mainline program), that is, a function with an attribute "constructor", the order of constructor execution is undetermined. This causes a problem if you link with the pthread library and perform any significant action within another constructor. The pthread library's pthread_initialize() function initializes the initial thread's struct _ptheread_descr_struct.p_errnop member to point to _errno, but if your constructor runs before pthread_initialize, then it is still at its default initial value of NULL. This causes probelems if your constructor makes a system call that fails and attempts to set errno, or calls any of the printf family, or probably other functions that touch errno. I think that this could be easily fixed if the initializer for __pthread_initial_thread specified &_errno for p_errnop (and &_h_errno for p_h_errnop) instead of NULL. I don't see any reason that it needs to be initialized to NULL. A way to produce the problem is: static void myfunc() __attribute__((constructor)); static void myfunc() { printf("hello"); } Build this into a shared library. Build another process that links with this library and the pthread library. If myfunc() runs before pthread_initialize(), then the printf() will try to touch errno and will cause a segmentation violation.
assign to jakub
This is fixed in glibc-2.1.92-14 and above.