public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* expected primary expression during make (seq24-0.6.3)
@ 2005-05-13 16:14 Esben Stien
  2005-05-15 17:29 ` Esben Stien
  2005-05-16 15:42 ` Nix
  0 siblings, 2 replies; 4+ messages in thread
From: Esben Stien @ 2005-05-13 16:14 UTC (permalink / raw)
  To: gcc-help

I'm trying to compile seq24-0.6.3 and get the following make
error. The developers of seq24 are baffled and don't know how to help
me and advised me to this list.

I'm also getting the exact same error with 0.6.2, 0.6.1 and 0.6.0.

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

mutex.cpp:24: error: expected primary-expression before '.' token
mutex.cpp:24: error: expected primary-expression before '{' token
mutex.cpp:24: error: expected `}' before '{' token
mutex.cpp:24: error: expected `,' or `;' before '{' token
mutex.cpp:24: error: expected declaration before '}' token
make[2]: *** [mutex.o] Error 1
make[2]: Leaving directory `/src/seq24-0.6.3/src'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/src/seq24-0.6.3/src'
make: *** [all-recursive] Error 1

The maintainer looked into the mutex.cpp source code (preprocessed
output)

line 24 is:
const pthread_mutex_t mutex::recmutex =
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;

which after preprocessing is:
const pthread_mutex_t mutex::recmutex = {0, 0, 0,
PTHREAD_MUTEX_RECURSIVE_NP, { 0, 0 }};

He said: "this sounds strange because there is no '.' token. Could you
verify this?"

I then replied with: 
gcc -E mutex.cpp gives me: 
const pthread_mutex_t mutex::recmutex = { .__data = { .__kind = PTHREAD_MUTEX_RECURSIVE_NP } };

My pthread.h file looks like this: 
http://esben-stien.name/goldenarms/pthread.h

A reply to this was: "All I can tell is your pthread.h file isn't
looking like most."

/* 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

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 } }

Any pointers on how to find out what's wrong?

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e 
           jid:b0ef@    n     n

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: expected primary expression during make (seq24-0.6.3)
  2005-05-13 16:14 expected primary expression during make (seq24-0.6.3) Esben Stien
@ 2005-05-15 17:29 ` Esben Stien
  2005-05-16 15:42 ` Nix
  1 sibling, 0 replies; 4+ messages in thread
From: Esben Stien @ 2005-05-15 17:29 UTC (permalink / raw)
  To: gcc-help

Esben Stien <b0ef@esben-stien.name> writes:

Hmm, any pointers on what lists I can take this to?

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e 
           jid:b0ef@    n     n

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: expected primary expression during make (seq24-0.6.3)
  2005-05-13 16:14 expected primary expression during make (seq24-0.6.3) Esben Stien
  2005-05-15 17:29 ` Esben Stien
@ 2005-05-16 15:42 ` Nix
  2005-05-17 18:13   ` Esben Stien
  1 sibling, 1 reply; 4+ messages in thread
From: Nix @ 2005-05-16 15:42 UTC (permalink / raw)
  To: Esben Stien; +Cc: gcc-help

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: expected primary expression during make (seq24-0.6.3)
  2005-05-16 15:42 ` Nix
@ 2005-05-17 18:13   ` Esben Stien
  0 siblings, 0 replies; 4+ messages in thread
From: Esben Stien @ 2005-05-17 18:13 UTC (permalink / raw)
  To: gcc-help

Nix <nix@esperi.org.uk> writes:

> This is a (now fixed) glibc bug

Nice.

> I don't know what distributor you use

I run my own distro.

> you could patch your installed header file straight from the `cvs
> diff' from glibc CVS

I downloaded glibc-2.3.4 and just replaced my pthread.h file. The diff
is posted at the bottom, just in case.

> doing so should be safe

Yes, my seq24 compiled just fine;). Thank you. I hope nothing else
breaks, but as you said, it looks safe.

-- 
Esben Stien is b0ef@e     s      a             
         http://www. s     t    n m
          irc://irc.  b  -  i  .   e/%23contact
          [sip|iax]:   e     e 
           jid:b0ef@    n     n

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-05-17 18:13 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-13 16:14 expected primary expression during make (seq24-0.6.3) Esben Stien
2005-05-15 17:29 ` Esben Stien
2005-05-16 15:42 ` Nix
2005-05-17 18:13   ` Esben Stien

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).