This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
- From: "john at johnmaddock dot co dot uk" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 19 May 2004 10:33:47 -0000
- Subject: [Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
- References: <20030817022106.11953.carlo@alinoe.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From john at johnmaddock dot co dot uk 2004-05-19 10:33 -------
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.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953