------- Comment #38 from carlo at gcc dot gnu dot org 2005-11-29 16:05 ------- That never works because it always defines _REENTRANT. You probably mean:
#ifdef _REENTRANT #define GCC_BUGFIX 1 #endif #include <iostream> #undef _REENTRANT #ifdef GCC_BUGFIX #define _REENTRANT 1 #endif The drawback of this "fix" is that it is hardly usable for library writers like you and me. You can add this to every .cpp file of an application, but it doesn't help to determine if the _user_ (of your library) wants thread-safeness or not. Such a user will add -pthread when compiling his application but we cannot detect that anymore. We can also not demand that users of our library add the above kludge at the top of every .cpp file of their application (before any system headers are included) or, equivalently, demand they include the header of our library before any system header. That being said, I obviously agree completely with Marc that this is a bug: _REENTRANT should only be defined by the compiler iff -pthread is passed to the compiler. I know that is not a written standard, but it certainly is widely used and something developers have come to rely on so much that it is pure arrogance to break it. I'd say, ignorance-- but given the fact that I reported this BEFORE it was released (after running into it in a cvs version), and it was released anyway... Nevertheless-- I've seen enough of the gcc development (that is, what is related with C++) to know that 'we' cannot rely on (the) g++ (developers) being interested in keeping backwards compatibility with ANYTHING that isn't set in stone by some ISO committee (refering to some GNU extensions here). Therefore I suggest to everyone reading this: don't rely on common sense. The define of _REENTRANT isn't some standard and therefore you cannot not rely on it (when using g++). Even if it was fixed in 4.1, you can count on it being broken again in 4.2. The only reliable "solution" left is to demand that the users define a macro on the command line. So, expect to see this kind of compilations in the future: g++ -pthread -DBOOST_THREAD_SAFE -DLIBCWD_THREAD_SAFE -DLIBXML2_THREAD_SAFE -DLIBC_THREAD_SAFE -DLIBFOO_THREAD_SAFE -DLIBGTK_THREAD_SAFE [...] application.cc until some guru proposes that all libraries make use of one and the same define: GURU_THREAD_SAFE. Unfortunately... two decades later, once that macro made it's way into AX[3.4]UbuOS-6.8 and some bug needs it to be defined always... g++ will think it's allowed to unconditionally define GURU_THREAD_SAFE too... because it wasn't an official standard [...] Yeah, history repeats itself. Watch and see. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
