This can't be right imho. >g++-3.3 troep.cc >a.out; echo $? 0 >g++-cvs-3.4 troep.cc >a.out; echo $? 1 Where >cat troep.cc #include <iosfwd> int main() { #ifdef _REENTRANT return 1; #else return 0; #endif } _REENTRANT is defined regardless in bits/gthr-default.h at the moment.
I can confirm this on the mainline (20030814) on i686-pc-linux-gnu but on powerpc-apple- darwin6.6 or i686-unknown-openbsd3.1 with the mainline (20030816) I cannot reproduce it. powerpc-apple-darwin6.6 and i686-pc-linux-gnu are configured with --enable-threads=posix, while i686-unknown-openbsd3.1 is not. I do not know what is going one.
This was done on purpose: +/* Some implementations of <pthread.h> require this to be defined. */ +#ifndef _REENTRANT +#define _REENTRANT 1 +#endif +
Subject: Re: _REENTRANT defined when compiling non-threaded code. On Sun, Aug 17, 2003 at 02:37:18AM -0000, pinskia at gcc dot gnu dot org wrote: > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953 > > > pinskia at gcc dot gnu dot org changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|NEW |RESOLVED > Component|libstdc++ |other > Resolution| |INVALID > > > ------- Additional Comments From pinskia at gcc dot gnu dot org 2003-08-17 02:37 ------- > This was done on purpose: > +/* Some implementations of <pthread.h> require this to be defined. */ > +#ifndef _REENTRANT > +#define _REENTRANT 1 > +#endif > + Yes, so? How is a developer supposed to know when an application is compiled with threading now? My code is FULL of #ifdef _REENTRANT ... #else ... #endif Suddenly all code that is compiled with the intension to be not thread-safe, and which will not be linked with libpthread.so is suddenly compiled as if it has to be thread-safe? Why was this done on purpose? It breaks a lot of code!
Carlo. I'm not going to comment on this issue directly, but instead will tell you that I've just learned that g++ doesn't define _REENTRANT on s390x and ia64 when --enable-threads=posix and using -pthread on the command line. (Found while compiling boost threads package on the afflicted platforms.) Supposdely this is a known issues. Thus, people who are using _REENTRANT as a macro to see if thread-enabled are already going to have problems. The suggestion, made elsewhere, is to use _POSIX_THREADS and check >= 0 (see unistd.h). Best, benjamin
No, it was not resolved. I think it is stupid indeed. I now detect the use of _REENTRANT before any headerfile is included; I can do that because I always include a custom "sys.h" as very first header in all my projects that I use to work around OS bugs. However, this still causes _REENTRANT to be defined or not defined purely depending on if some standard header was or was not included yet - and as such breaks third party libraries that depend directly on _REENTRANT. On Thu, Apr 15, 2004 at 04:44:06PM +0800, Yu Wang wrote: > Hi, Carlo, > I found your email from gcc.gnu.org archives, in finding the solution > for a same problem you met(quoted below). My gcc version is 3.3.2 > (release). Could you told me how is your status on this?Is it solved? > Any help would be appreciated. > > Regards. > Yu
*** Bug 15415 has been marked as a duplicate of this bug. ***
Bug 15415 relates to problems using Boost due to this issue, which I don't think is INVALID. Ben's suggestion of using _POSIX_THREADS >= 0 doesn't work either, as it is also defined whether you use -pthread or not (at least on Linux and FreeBSD) Would it be possible for all relevant platforms to define something such as _GXX_PTHREADS when -pthread is given? This would allow Boost to reliably detect whether or not to use threadsafe constructs when compiled with G++ 3.4
Let's reopen it. I believe that this causes significant grief to application writers, and defining system flags like these that have traditionally been set on the command line is at least not very good style. If unnecessary, it should be done only for those platforms where it really is necessary. It would be good if everyone would try to think hard again and figure out a way to work around this problem. The idea of defining something like __GXX_PTHREADS__ or similar wouldn't be such a bad idea -- after all we already have a number of other command line options that do similarly. W.
Please do not reopen this bug unless you engage the original author of the patch that broke it (e.g. ro). Users should not be writing code which depends on the state of _REENTRANT. Like Benjamin I will only comment indirectly: I will just state that every other port which enabled threading support did not require this define to be (unconditionally) blasted into gthr-posix.h . Every other port figured out how to stuff it in port-specific places. I don't know if Rainer should be asked to rework his thread support for alpha*-dec-osf[45]*... (but that would be my choice to properly close this bug even though I don't think portable code should even use this macro's state in any way)
IMO there are several issues here: 1) Documentation - the thread compiler options are undocumented currently. 2) Consistency - we currently appear to have -pthread (Linux) -pthreads (solaris) -mthread (mingwin), or nothing required (BSD, cygwin). Please can we have some kind of consistent policy here? 3) The C++ headers should not be defining a symbol that's normally defined on the compiler command line (and usually by the appropriate compiler option rather than a direct define). 4) It would be nice if _REENTRANT was a compiler define when it's in thread- safe mode - that's the way most other compiler vendors handle it (although some spell it _MT :-) ). Regards, John Maddock.
Subject: Re: _REENTRANT defined when compiling non-threaded code. ljrittle at gcc dot gnu dot org writes: > Please do not reopen this bug unless you engage the original author of the patch > that broke it (e.g. ro). Users should not be writing code which depends on the > state of _REENTRANT. Exactly: I have yet to see some normative text stating that _REENTRANT must not be defined without threading support enabled. So far the assertions have only been `we have always used it to determine if threading support is available', but no indication whatsoever why this is necessary and why they use _REENTRANT for that purpose. Proper tests should test for the respective functions instead, it seems. > Like Benjamin I will only comment indirectly: I will just state that every other > port which enabled threading support did not require this define to be > (unconditionally) blasted into gthr-posix.h . Every other port figured out how > to stuff it in port-specific places. I don't know if Rainer should be asked to > rework his thread support for alpha*-dec-osf[45]*... (but that would be my > choice to properly close this bug even though I don't think portable code should > even use this macro's state in any way) I can try to stuff this definition into a (new) config/os/osf/os_defines.h, but that means I'll have to duplicate config/os/generic/ctype_* to allow this. Rainer
Rainer, Admittedly, Boost was never correct to use that macro, but the fact remains that the change has caused problems that Boost must now address. If there is a better way to tell (at preprocessing stage) whether g++ will link to the real pthread_* symbols or the weak ones defined in gthr-posix.c I'm sure the Boost developers would be glad to use it. Detecting _REENTRANT used to work on linux and other key platforms and so my naive opinion is that a similar, but documented and cross-platform, macro such as __GXX_PTHREADS__ would serve the purpose better. If something like this were acceptable I'd help the work where possible (is there an easier way than adding it to the all the config/${cpu}/*.h files for relevant platforms?)
To respond to your recent comments, here's the history: There are a number of compilers which can compile code in either "thread safe mode", or "non thread safe mode" depending upon which compiler switches are passed to the C++ front end. Some of these compilers use _MT to indicate that they are in thread safe mode (the Windows ones), and some commercial Unix compilers use _REENTRANT for this (don't ask me which ones I've lost my the right now). Gcc historically didn't touch _REENTRANT at all, so we were safe in detecting this macro to test to see if the compiler was *capable* of producing thread safe code. Note that testing for the presence of _POSIX_THREADS or whatever is *not* sufficient: that tells you whether the OS has the POSIX thread API's or not, it does not tell you whether the C++ compiler you are using will generate thread safe code or not (the C++ runtime, and in particular the exception handling code needs to be thread safe, if that's not the case the code will compile and link, but will likely crash if a thread throws an exception, obviously I'm generalising here, because the details depend on the compiler). In this respect C++ compilers are different from native platform C compilers, which can use _POSIX_THREADS. Moving back to gcc.... I believe that if the compiler is configured with -- disable-threads, the underlying platform will still report that _POSIX_THREADS is set won't it? Even though the compiler itself is incapable of producing thread safe code in this configuration. As a next best approximation, we can test to see if libstdc++ has been configured with threads on, by detecting the undocumented macro _GLIBCXX_HAVE_GTHR_DEFAULT, but you know that's not right either. Regards, John Maddock.
Can we conditionalize the definition of _REENTRANT only for those platforms whose POSIX threads implementation really does depend on this?
Subject: Re: _REENTRANT defined when compiling non-threaded code. mmitchel at gcc dot gnu dot org writes: > Can we conditionalize the definition of _REENTRANT only for those platforms > whose POSIX threads implementation really does depend on this? That would be one possibility. Currently, only Tru64 UNIX V5.1[AB] is known to need this. Otherwise, a patch like the following would be necessary, which is really ugly. It requires every user of gthr.h to define _REENTRANT for Tru64 UNIX (or other platforms that need might it), even without knowing if pthreads are in use at all. Currently, libjava has a mechanism for platform-specific defines, while libobjc (the other gthr.h user) has not. Rainer Index: gcc/gthr-posix.h =================================================================== RCS file: /cvs/gcc/gcc/gcc/gthr-posix.h,v retrieving revision 1.28 diff -u -p -r1.28 gthr-posix.h --- gcc/gthr-posix.h 28 May 2004 20:18:23 -0000 1.28 +++ gcc/gthr-posix.h 9 Jun 2004 14:09:19 -0000 @@ -35,11 +35,6 @@ Software Foundation, 59 Temple Place - S #define __GTHREADS 1 -/* Some implementations of <pthread.h> require this to be defined. */ -#ifndef _REENTRANT -#define _REENTRANT 1 -#endif - #include <pthread.h> #include <unistd.h> Index: gcc/config/alpha/t-osf-pthread =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/alpha/t-osf-pthread,v retrieving revision 1.1 diff -u -p -r1.1 t-osf-pthread --- gcc/config/alpha/t-osf-pthread 31 Jul 2003 12:01:06 -0000 1.1 +++ gcc/config/alpha/t-osf-pthread 9 Jun 2004 14:09:21 -0000 @@ -2,4 +2,4 @@ LIB2FUNCS_EXTRA += $(srcdir)/gthr-posix.c # Compile libgcc2 with POSIX threads supports -TARGET_LIBGCC2_CFLAGS=-pthread +TARGET_LIBGCC2_CFLAGS += -pthread Index: libobjc/thr-objc.c =================================================================== RCS file: /cvs/gcc/gcc/libobjc/thr-objc.c,v retrieving revision 1.3 diff -u -p -r1.3 thr-objc.c --- libobjc/thr-objc.c 23 May 2003 20:25:39 -0000 1.3 +++ libobjc/thr-objc.c 9 Jun 2004 14:10:43 -0000 @@ -30,6 +30,10 @@ Boston, MA 02111-1307, USA. */ #include "defaults.h" #include <objc/thr.h> #include "runtime.h" +/* Tru64 UNIX V5.1[AB] <pthread.h> requires this to be defined. */ +#ifndef _REENTRANT +#define _REENTRANT 1 +#endif #include <gthr.h> /* Backend initialization functions */ Index: libstdc++-v3/configure.host =================================================================== RCS file: /cvs/gcc/gcc/libstdc++-v3/configure.host,v retrieving revision 1.25 diff -u -p -r1.25 configure.host --- libstdc++-v3/configure.host 27 Feb 2004 20:56:43 -0000 1.25 +++ libstdc++-v3/configure.host 9 Jun 2004 14:10:43 -0000 @@ -184,6 +184,9 @@ case "${host_os}" in netbsd*) os_include_dir="os/bsd/netbsd" ;; + osf*) + os_include_dir="os/osf" + ;; qnx6.[12]*) os_include_dir="os/qnx/qnx6.1" c_model=c with libstdc++-v3/config/os/osf containing copies of the generic ctype*.h files and os_defines.h changed like this: --- ../generic/os_defines.h Mon Jul 7 13:29:14 2003 +++ os_defines.h Mon May 24 17:08:38 2004 @@ -1,6 +1,6 @@ -// Specific definitions for generic platforms -*- C++ -*- +// Specific definitions for HP Tru64 UNIX -*- C++ -*- -// Copyright (C) 2000 Free Software Foundation, Inc. +// Copyright (C) 2004 Free Software Foundation, Inc. // // This file is part of the GNU ISO C++ Library. This library is free // software; you can redistribute it and/or modify it under the @@ -34,4 +34,9 @@ // System-specific #define, typedefs, corrections, etc, go here. This // file will come before all others. +// Tru64 UNIX V5.1[AB] <pthread.h> requires this to be defined. +#ifndef _REENTRANT +#define _REENTRANT 1 +#endif + #endif
Subject: Re: _REENTRANT defined when compiling non-threaded code. > > > ------- Additional Comments From ro at techfak dot uni-bielefeld dot de 2004-06-09 19:24 ------- > Subject: Re: _REENTRANT defined when compiling non-threaded code. > > mmitchel at gcc dot gnu dot org writes: > > > Can we conditionalize the definition of _REENTRANT only for those platforms > > whose POSIX threads implementation really does depend on this? > > That would be one possibility. Currently, only Tru64 UNIX V5.1[AB] is > known to need this. > > Otherwise, a patch like the following would be necessary, which is really > ugly. It requires every user of gthr.h to define _REENTRANT for Tru64 UNIX > (or other platforms that need might it), even without knowing if pthreads > are in use at all. Currently, libjava has a mechanism for > platform-specific defines, while libobjc (the other gthr.h user) has not. The libobjc part is fine with me since there is no need for platform-specific defines as the header file is only included the sources of libobjc and never included with from any user code. Thanks, Andrew Pinski
Subject: Re: _REENTRANT defined when compiling non-threaded code. pinskia at physics dot uc dot edu writes: > The libobjc part is fine with me since there is no need for platform-specific > defines as the header file is only included the sources of libobjc and never > included with from any user code. I'd prefer guarding the _REENTRANT definition in gthr-posix.h nonetheless, since it centralizes the ugliness in one place (if this is necessary at all, which I'm not really convinced yet, and neither several other reviewers, it seems). Anyway, I'll be away until June 15th in a few minutes, so this will have to wait until then. Rainer
Postponed until GCC 3.4.2.
Sorry guys, I'm just getting back to this. Ranier, I think you are right: we should make an osf directory, dupe the files, and remove the gthr-posix.h unconditional defines. Do you want to do this? Let's try to fix this for 3.4.2. I think this is a high priority bug BTW. I have to say that John Maddock really does have a huge point with the consistency issue. It's incredibly annoying that -pthreads/-pthread/-mthread even exist, when -pthread across all would have been much, much better. Why does gcc do this crazy stuff? Ugh. I guess we cannot fix this particular bit for 3.4.2, although, quite frankly, we should. -benjamin
Would it be possible to add a caveat to http://gcc.gnu.org/gcc-3.4/changes.html saying that users of Boost (on Linux at least) might get linker errors, which can be avoided by _either_ compiling with -pthread, _or_ defining BOOST_DISABLE_THREADS ? I can supply the wording if wanted.
Jonathan: I think it makes sense. Prepare a HTML patch against changes.html and send it to gcc-patches@gcc.gnu.org.
Postponed until GCC 3.4.3.
*** Bug 17398 has been marked as a duplicate of this bug. ***
I've finally sent a wwwdocs patch to gcc-patches for approval. http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00736.html
This wording is very boost specific and does not give a solution for other libraries that need to detect at prepocessing time whether or not -pthread is being used. Consider a library libjohndoe, this library comes in two flavours: one that is not thread-safe (-ljohndoe) and one that is thread-safe, but considerably slower and larger so that users really only want to use it when they are actually using threads (-ljohndoe_r). The header files of libjohndoe also need to adjust prototypes and macros based on whether a user is linking with -ljohndoe or -ljohndoe_r, so a macro is needed. If that macro is not provided by -pthreads, then the users of libjohndoe will be forced to provide it themselfs: g++ app.cc -ljohndoe or g++ -pthread app.cc -DMT_JOHNDOE -ljohndoe_r -lpthread In my opinion that is the same as when users of Tru64 are forced to define _REENTRANT when including pthread.h and when that is not acceptable then forcing user-defined macros to be defined in order to tell whether or not an application is expected to be thread-safe (while previous this was not necessary) seems at least to be undesirable. Most importantly however - it is totally unnecessary. At all times there will be this -pthread commandline option that imho has exactly the meaning that we are looking for: This application is using threads and needs thread-safe libraries. Wouldn't it be a very reasonable and logical solution to define some, any, macro when -pthread is used on the command line? It would solve my problem and it would solve boosts problem, and it would solve the problem of the author of libjohndoe too. I think this new macro really must be added to 4.0.0 before its release.
Carlo, I realise the text (which I've committed btw) is quite Boost-specific, that's because 1) Boost is the only code I use which is affected by this PR (selfish, I know) 2) Boost is the only library for which a simple workaround is given on this PR.
I've been thinking about this PR, probably too much. I assume my concerns are unfounded, or we'd have noticed bigger problems by now, but here goes: The change to gthr-posix.h means that if GCC is configured with thread-support on Tru64 then it _always_ compiles thread-safe programs, even when -pthread is not used. The only way to prevent that is to configure with --disable-threads. Carlo said in comment #25 that this means even single-threaded apps will use slower, reentrant versions of libs. For system libs, this is not true, because if -pthread is not given then the reentrant libs won't be linked to, even though _REENTRANT was defined. Is it even well-formed to define _REENTRANT and include <pthread.h> but _not_ link to the reentrant libs? Tru64's <pthread.h> (at least, the fixincluded version) says: * You should always define _REENTRANT on the command line, usually by using * "cc -pthread" or "cxx -pthread", to be sure that it will be available for * all header files. This recommendation is not followed by gthr-posix.h, which defines _REENTRANT only before including <pthread.h>. Not all libstdc++ headers include gthr-posix.h, so _REENTRANT won't always be defined e.g. <utility> doesn't include gthr-posix.h, so in this code: #include <utility> #include <unistd.h> #include <iostream> _REENTANT will not be defined when unistd.h is included. The above comment from Tru64's pthread.h is followed by "#include <unistd.h>" which will have no effect if that file was already included before _REENTRANT was defined. Rainer's proposal to put _REENTRANT in os_defines.h will ensure that _REENTRANT is always defined, but it won't get around the issue of including thread-safe definitions but not linking to them (but maybe that's a non-issue). Would it be possible to only include <pthread.h> if _REENTRANT is defined, and include some <pthread-dummy.h> otherwise, which just has dummy decls for the pthread_xxx() functions needed by gthreads? That way whether reentrant code is used would depend on whether -pthread was used, as is intended. I have very litle experience with either MT or Tru64, so probably haven't got this analysis right, I'm just trying to understand the issues better.
Postponed until GCC 3.4.4.
Did we decide this is a bug or not?
Subject: Re: _REENTRANT defined when compiling non-threaded code. On Mon, Jun 13, 2005 at 03:29:02AM -0000, pinskia at gcc dot gnu dot org wrote: > ------- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-13 03:29 ------- > Did we decide this is a bug or not? Strictly speaking, it is not a bug AFAICT because gcc does not violate any standard. However, current gcc releases make the life unnecessarily hard for developers because there is no way to decide at compile time (more precisely: in the preprocessing stage) whether g++ will link against the "real" pthread_* symbols. They have to resort to their own preprocessor macros MY_LIB_USE_THREADS and rely on their users who include the respective headers to (un-)define those macros correctly. So it is a QoI issue. (If I am not mistaken then gcc is the only compiler for which the Boost libraries cannot detect automatically whether the code needs to support MT.) Perhaps I am missing something, but wouldn't it be sufficient if gcc defined a dedicated preprocessor constant whenever the option -pthreads was found on the command line? (I know next to nothing about the gcc source code, so I cannot say whether that would be straightforward to implement.) Regards Christoph
The option inconsistency between platforms is bug 20705. I agree there should be a #define that says whether POSIX threads are usable (rather than just supported by the platform), but I think _REENTRANT is the wrong #define to use. This applies to both C and C++, so the name should be something like __GCC_PTHREADS__, not __GXX_PTHREADS__.
<http://gcc.gnu.org/ml/libstdc++/2002-02/msg00231.html> suggests defining __GNUC_THREADMODEL__ to a string specifying the thread model.
Should a separate PR be opened requesting __GCC_PTHREADS__, so this PR can focus on whether _REENTRANT should be defined unconditionally and discussion of an alternative macro can take place separately? I have the beginnings of a patch to define __GCC_PTHREADS__ whenever -pthread is given if that would help. It's incomplete, as not all gcc/config/* files use -pthread in the CPP_SPEC and I have only added -D__GCC_PTHREADS__ where CPP_SPEC already does something for -pthread/-pthreads. If I'm not wasting my time I'll finish it off.
What now? What happened since July? There's not even a new trouble report open asking for "__GCC_PTHREADS__". What can I as library writer now do, if I want to know whether or not I am in valid multithreaded environment, and if I don't want to force my clients to use silly defines like "-pthreads -DWE_HAVE_MULTIHREADING"? Especially, there are tons of code reliyng on the "#ifdef _REENTRANT" check, so breaking this compatibility was really stupid! But the wort thin is, that there is not even an equivalent replacement, not even in gcc release 4.0.2! If other compilor vendors use either _REENTRANT or _MT to distiguish multithreaded from non-threaded environments, gcc should do it exactly the same way, and not introduce seomething new and compiler dependent! Now, to be backward compatible, I have to modify my code in the way: #if (__GNUC__==3 && __GNUC_MINOR__>=4 || __GNUC__>3) && MY_SILLY_FLAG || (__GNUC__==3 && __GNUC_MINOR__<4 || __GNUC__<3) && _REENTRANT || _MT // multithreaded code here #endif and to tell my clients to add -DMY_SILLY_FLAG in addition to -pthread if they use gcc>=3.4 and want threadsafe code. Or, slightly better, use "_MT" and define _MT automatically if possible, or have to add -D_MT otherwise: #if (__GNUC__==3 && __GNUC_MINOR__<4 || __GNUC__<3) && _REENTRANT #define _MT #endif [...] #ifdef _MT // multithreaded code here #endif Any better idea?!? I would cleary declare this breaking with backward-compatibility as a major bug in gcc!
I had a look in google about "#ifdef _REENTRANT", and it gets about 20'200 entries, so this is a widely used funtinality that must not be broken! Imagine all the code the does the "#ifdef _REENTRANT" to enable threading: If now _REENTRANT is always true, regardless of whether -pthreads is given or not, then all this code will crash when compiled with gcc += 3.4! This is really a severe problem! Please return to the previous behaviour of _REENTRANT, and fix it for those platforms, where it previousely did not work (s390x and ia64). The _REENTRANT must work as 90% of the programmers expect it to work! It wasn't my idea to look for _REENTRANT, i learnt it from a collegue who has seen it in system C libraries and e.g. the QpThread library. It is a widely used feature! It must neither be broken, nor be replaced by something else, sich as __GCC_PTHREADS__ or the like! In errno.h, AFAIK they also tested for _REENTRANT, now they test for: # if !defined _LIBC || defined _LIBC_REENTRANT Is this an acceptable way to do it now, test for _LIBC_REENTRANT? Reentrant is also used in /usr/include/features.h: /* These are defined by the user (or the compiler) to specify the desired environment: [...] _REENTRANT Select additionally reentrant object. _THREAD_SAFE Same as _REENTRANT, often used by other systems. [...] */ --> So it should be set correctly by the compiler!!!! #if defined _REENTRANT || defined _THREAD_SAFE # define __USE_REENTRANT 1 #endif
New information: _REENTRANT is definitively defined in the headers: > echo "" | g++ \ -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \ -E -dM -c - | grep REENTRANT > echo "" | g++ \ -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \ -E -dM -c -pthread - | grep REENTRANT #define _REENTRANT 1 > echo "#include<iostream>" | g++ \ -I /usr/include/c++/4.0.2 -I /usr/include/c++/4.0.2/i586-suse-linux \ -E -dM -c - | grep REENTRANT #define _REENTRANT 1 #define _POSIX_REENTRANT_FUNCTIONS 1 --> So, without "#include <iostream>" it works as expected! This opens a new possibility to work around this bug: --------------file.cpp #define GCC_BUGFIX _REENTRANT #include <iostream> #include ... #undef _REENTRANT #define _REENTRANT GCC_BUGFIX #ifdef _REENTRANT ... #endif ---------------------- > g++ -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,f95,java,ada --disable-checking --with-gxx-include-dir=/usr/include/c++/4.0.2 --enable-java-awt=gtk --disable-libjava-multilib --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit --without-system-libunwind --host=i586-suse-linux Thread model: posix gcc version 4.0.2 20050901 (prerelease) (SUSE Linux)
Correction: The above work around only works, as long, as your file is not included by another file...
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.
Subject: Bug 11953 Author: jakub Date: Fri Feb 17 21:49:22 2006 New Revision: 111212 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111212 Log: PR libstdc++/11953 * gthr-posix.h (_REENTRANT): Only define if __osf__ is defined. * config/ia64/linux.h (CPP_SPEC): Define. * config/s390/linux.h (CPP_SPEC): Define. Modified: branches/redhat/gcc-4_1-branch/gcc/ChangeLog branches/redhat/gcc-4_1-branch/gcc/config/ia64/linux.h branches/redhat/gcc-4_1-branch/gcc/config/s390/linux.h branches/redhat/gcc-4_1-branch/gcc/gthr-posix.h
Fixed in 4.1. and up.
the patch was applied in the redhat/gcc-4_1-branch, not in the gcc-4_1-branch. either the target milestone should be changed or the bug reopened. Matthias
This bug (against the regular development branches) should not be marked fixed simply because a patch was applied to the redhat branch. Either it needs to go into mainline 4.1, or the bug needs to be closed in some other manner. I am simply reopening it because it looks like it hasn't actually been resolved. I have no opinion on any of the actual issues involved :)
Subject: Bug 11953 Author: jakub Date: Tue Dec 12 15:15:19 2006 New Revision: 119788 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119788 Log: PR libstdc++/11953 * gthr-posix.h (_REENTRANT): Only define if __osf__ is defined. * config/ia64/linux.h (CPP_SPEC): Define. * config/s390/linux.h (CPP_SPEC): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/linux.h trunk/gcc/config/s390/linux.h trunk/gcc/gthr-posix.h
Subject: Bug 11953 Author: jakub Date: Tue Dec 12 15:21:53 2006 New Revision: 119789 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119789 Log: PR libstdc++/11953 * gthr-posix.h (_REENTRANT): Only define if __osf__ is defined. * config/ia64/linux.h (CPP_SPEC): Define. * config/s390/linux.h (CPP_SPEC): Define. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/ia64/linux.h branches/gcc-4_2-branch/gcc/config/s390/linux.h branches/gcc-4_2-branch/gcc/gthr-posix.h
Subject: Bug 11953 Author: jakub Date: Tue Dec 12 15:24:07 2006 New Revision: 119790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119790 Log: PR libstdc++/11953 * gthr-posix.h (_REENTRANT): Only define if __osf__ is defined. * config/ia64/linux.h (CPP_SPEC): Define. * config/s390/linux.h (CPP_SPEC): Define. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/ia64/linux.h branches/gcc-4_1-branch/gcc/config/s390/linux.h branches/gcc-4_1-branch/gcc/gthr-posix.h
Fixed.
Subject: Bug 11953 Author: doko Date: Sun Dec 17 13:46:58 2006 New Revision: 119986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119986 Log: 2006-12-17 Matthias Klose <doko@debian.org> PR libstdc++/11953 * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/linux.h
Subject: Bug 11953 Author: doko Date: Sun Dec 17 13:53:07 2006 New Revision: 119987 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119987 Log: 2006-12-17 Matthias Klose <doko@debian.org> PR libstdc++/11953 * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/mips/linux.h
Subject: Bug 11953 Author: doko Date: Sun Dec 17 13:57:31 2006 New Revision: 119988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119988 Log: 2006-12-17 Matthias Klose <doko@debian.org> PR libstdc++/11953 * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/mips/linux.h
that solved the problem thanks, most of these bugs are now solved and corrected, i do not think bug is the correct word anyway, this is my bodybuilding blog called deniserutkowski check it out http://deniserutkowski.blogspot.co.uk/