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

["carlo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From carlo at gcc dot gnu dot org  2004-10-08 13:53 -------
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.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953