expected primary expression during make (seq24-0.6.3)

[Nix]

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@redhat.com>

        * 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