Bugzilla Bug 45115

g++ refuses to compile C++ code that uses one of the pthread.h declared macros
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
or PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP.

Reproducible: Always
Steps to Reproduce:
Try to compile following simple C++ source:
#include <pthread.h>
pthread_mutex_t mymutex = PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP;

2.
3.

Actual Results:  
error: parse error before `.' token 

Expected Results:  
AFAIK this *is* the expected result, as GNU C++ does not support the designated 
initializer extension that is used in pthread.h to declare the macros mentioned 
above. 

Possible solution: Change pthread.h to use non-designated initializers instead. 

My configuration: 
sys-libs/glibc-2.3.3_pre20040207 with NPTL 
sys-devel/gcc-3.3.3 

More info: http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

Created an attachment (id=27608) [details]
Proposed patch for pthread.h to use non-designated initializers.

Sorry nobody commented on your bug sooner. 
Is this still a valid problem? 
If so would the upstream gnu maintainers be a better place?

Yes, still valid as of sys-libs/glibc-2.3.4.20040808 + NTPL and
sys-devel/gcc-3.3.4-r1.

And the pthread.h patch given above still applies cleanly, too.

I found out about this when getting the compile error mentioned above on some
sound-related package from CVS (sorry, I dont remember which), which was solved
by compiling against the patched pthread.h

This patch applies only a formal change to pthread.h to make it useable with
current GCC specs (that simply and explicitly do not support that initalizer
style, see link above). I dont know about implications with other compilers,
but I think the patched initializer style should be the common one (as the GCC
refers to the current one as "designated initializer *extension*" ;-)

Yes, I think upstream may be appropriate. You (or "Gentoo the distro") handle
upstream communication, right?

Sometimes we do.

Before adding this patch I want to make sure we are doing the right 
thing and it is usually better that things like this be fixed for 
everybody in gnuland vs just us.

So I think in this case as you understand the problem better than we do, 
that you should make contact with the gnu folk. 

Report what you know and provide a test case if you can. Wait for 
feedback, update this bug. 

Provide url's if possible to relevant threads so we can track the
progress together.

Ok, filed bug <a
href="http://sources.redhat.com/bugzilla/show_bug.cgi?id=359">#359 -
PTHREAD_[...]_INITIALIZER_NP macros from pthread.h break GNU C++
compilation</a> against glibc.

Oops, no embedded HTML allowed ? ;-)

This bug can be seen on compiling FLTK-1.1.5rc2 from sources;

Fltk_init.cxx: 133: error: parse error before `.' token 
[...]

Applying the proposed pthread.h patch resolves to clean compilation.

Regards,
Dario Birtic

FYI, this bug breaks gcc 3.4.2_pre20040902; pthread is used in the libstdc++
stuff. Expect some dupes.

It seems to me that perhaps just modifying the 
    #ifdef __USE_GNU 
to
    #if defined(__USE_GNU) && !defined(__cplusplus) 
would be more conservative? That is, making the initialiser be defined only
under GCC/C, where at present it is defined also under GCC/C++. 

Or would this break some applications? It seems to me otherwise, as usage under
GCC/C++ would be all that is affected, and that can never have compiled anyway.
(Gotta wonder what the libstdc++ guys were thinking...)

i cant reproduce this.

ayanami root # g++ -shared pthread.c
ayanami root #

using glibc 2.3.4.20040808 on amd64

Bug has been closed at RH with the comment that it's been fixed upstream.
http://bugs.gentoo.org/show_bug.cgi?id=45115

url correction. http://sources.redhat.com/bugzilla/show_bug.cgi?id=359

please test the latest glibc snapshot from today

Fix confirmed against snapshot glibc-20040913. File
glibc-20040913/nptl/sysdeps/pthread/pthread.h does not
use designated initializers any more for those types.

that snapshot was removed for other bugs, but 0918 is in the tree now. please
test :)

Ok, fix verified for current portage (as of 2004-09-22)
sys-libs/glibc-2.3.4.20040808.

Just out of curiosity, what is the current bug closing policy? CLOSE (and
thereby effectively hide from John Doe) as soon as fixed on the bleeding edge
or keep as RESOLVED until the fix has finally reached the non ~ARCH world, too?

Sorry to ask, but I could not find any docs about this myself. The link
http://bugs.gentoo.org/bugwritinghelp.html on "What is all of this?"
(advertised there as "very important, and should be heeded" ;-) seems to be
broken.

Only other doc I found was at http://www.gentoo.org/doc/en/policy.xml#doc_chap4
under "Moving package versions from ~ARCH to ARCH", where it states "An
indication of the package's stability would be no verified or unresolved bug
report for a month after the version's introduction." (what IMHO seems to
promote the "keep as RESOLVED until in stable" variant).

Damn, I always forget that this for any reason does no line break itself.
Sorry folks ;-)