------- 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
