This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.

------- Comment #34 from marc dot waeckerlin at siemens dot com  2005-11-28 13:37 -------
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

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
#ifdef _MT
// multithreaded code here

Any better idea?!?

I would cleary declare this breaking with backward-compatibility as a major bug
in gcc!


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]