On 13 May 2005, Esben Stien yowled: > I'm on linux-2.6.12-rc1-RT-V0.7.41-15 on a p3-600, > glibc-2.3.4-20040828 and gcc-3.4.2 This is a (now fixed) glibc bug. See <http://sourceware.org/bugzilla/show_bug.cgi?id=375>. > A reply to this was: "All I can tell is your pthread.h file isn't > looking like most." I'd guess that he was looking at the LinuxThreads pthread.h, not the NPTL one. The LinuxThreads header never used designated initalizers. > /* Mutex initializers. */ > #define PTHREAD_MUTEX_INITIALIZER \ > { } > #ifdef __USE_GNU > # define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \ > { .__data = { .__kind = PTHREAD_MUTEX_RECURSIVE_NP } } > # define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \ > { .__data = { .__kind = PTHREAD_MUTEX_ERRORCHECK_NP } } > # define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \ > { .__data = { .__kind = PTHREAD_MUTEX_ADAPTIVE_NP } } > #endif This is an NPTL pthread.h file. (Most distributors install the LinuxThreads header, not the NPTL one, and most users never realise there is a difference.) > He said: "I'm not even sure if that is valid code?. The above code > looks like this in my 2.3.4.20040808:" > > # define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP \ > { { 0, 0, 0, PTHREAD_MUTEX_RECURSIVE_NP } } > # define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP \ > { { 0, 0, 0, PTHREAD_MUTEX_ERRORCHECK_NP } } > # define PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP \ > { { 0, 0, 0, PTHREAD_MUTEX_ADAPTIVE_NP } } This indeed is a LinuxThreads pthread.h header. > Any pointers on how to find out what's wrong? The bug was fixed here: 2004-09-08 Ulrich Drepper <drepper@xxxxxxxxxx> * sysdeps/pthread/pthread.h (PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP): Make safe for C++. (PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP): Likewise. (PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP): Likewise. (PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP): Likewise. [BZ #375] and is in both glibc-2.3.4 and 2.3.5. I don't know what distributor you use, but I'd hope it's got an update to glibc that fixes this. (Or you could patch your installed header file straight from the `cvs diff' from glibc CVS: it doesn't change binary compatibility, so doing so should be safe.) -- `End users are just test loads for verifying that the system works, kind of like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s
