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 attachment 27608 [details, diff] 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 ;-)
