[Bug c++/11953] New: _REENTRANT defined when compiling non-threaded code.

[Bug c++/11953] New: _REENTRANT defined when compiling non-threaded code.

[carlo at alinoe dot com]

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

           Summary: _REENTRANT defined when compiling non-threaded code.
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: carlo at alinoe dot com
                CC: gcc-bugs at gcc dot gnu dot org

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.

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

[pinskia at gcc dot gnu dot org]

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|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-08-17 02:28:11
               date|                            |


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-17 02:28 -------
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.

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

[pinskia at gcc dot gnu dot org]

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
+

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

[carlo at alinoe dot com]

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



------- Additional Comments From carlo at alinoe dot com  2003-08-17 02:56 -------
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!

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

[bkoz at gcc dot gnu dot org]

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



------- Additional Comments From bkoz at gcc dot gnu dot org  2003-09-10 12:55 -------
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

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

[carlo at gcc dot gnu dot org]

------- Additional Comments From carlo at gcc dot gnu dot org  2004-04-15 13:22 -------
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


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-13 10:53 -------
*** Bug 15415 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cludwig at cdc dot
                   |                            |informatik dot tu-darmstadt
                   |                            |dot de


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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2004-05-13 11:15 -------
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


-- 


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

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

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-05-13 22:54 -------
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. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
          Component|other                       |libstdc++
         Resolution|INVALID                     |


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

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

[ljrittle at gcc dot gnu dot org]

------- Additional Comments From ljrittle at gcc dot gnu dot org  2004-05-14 01:27 -------
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)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at techfak dot uni-
                   |                            |bielefeld dot de


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

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

[john at johnmaddock dot co dot uk]

------- Additional Comments From john at johnmaddock dot co dot uk  2004-05-14 10:40 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john at johnmaddock dot co
                   |                            |dot uk


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

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

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.0                       |3.4.1


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

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

[ro at techfak dot uni-bielefeld dot de]

------- Additional Comments From ro at techfak dot uni-bielefeld dot de  2004-05-18 18:40 -------
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


-- 


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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2004-05-18 21:21 -------
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?)

-- 


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

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

[john at johnmaddock dot co dot uk]

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

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

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-06-09 19:18 -------
Can we conditionalize the definition of _REENTRANT only for those platforms
whose POSIX threads implementation really does depend on this?


-- 


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

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

[ro at techfak dot uni-bielefeld dot de]

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

	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


-- 


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

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

[Andrew Pinski]

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

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

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2004-06-09 19:30 -------
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



-- 


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

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

[ro at techfak dot uni-bielefeld dot de]

------- Additional Comments From ro at techfak dot uni-bielefeld dot de  2004-06-09 19:37 -------
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


-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-06-18 23:41 -------
Postponed until GCC 3.4.2.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.1                       |3.4.2


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

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

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-07-20 00:50 -------

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

-- 


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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2004-07-22 13:19 -------
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.


-- 


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

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

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-07-22 13:40 -------
Jonathan: I think it makes sense. Prepare a HTML patch against changes.html and 
send it to gcc-patches@gcc.gnu.org.

-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-08-19 20:30 -------
Postponed until GCC 3.4.3.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.2                       |3.4.3


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-10 15:25 -------
*** Bug 17398 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |william dot crocker at
                   |                            |analog dot com


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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2004-10-08 13:13 -------
I've finally sent a wwwdocs patch to gcc-patches for approval.

http://gcc.gnu.org/ml/gcc-patches/2004-10/msg00736.html


-- 


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

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

[carlo at gcc dot gnu dot 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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2004-10-11 11:39 -------
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.



-- 


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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2004-10-11 12:22 -------
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.


-- 


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

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

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-10-30 19:37 -------
Postponed until GCC 3.4.4.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.3                       |3.4.4


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

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

[mmitchel at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.4.4                       |3.4.5


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

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

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-06-13 03:29 -------
Did we decide this is a bug or not?

-- 


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

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

[cludwig at cdc dot informatik dot tu-darmstadt dot de]

------- Additional Comments From cludwig at cdc dot informatik dot tu-darmstadt dot de  2005-06-14 13:19 -------
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


-- 


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

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

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW


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

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

[david dot nospam dot hopwood at blueyonder dot co dot uk]

------- Additional Comments From david dot nospam dot hopwood at blueyonder dot co dot uk  2005-07-29 11:25 -------
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__.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|16519                       |20705


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

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

[david dot nospam dot hopwood at blueyonder dot co dot uk]

------- Additional Comments From david dot nospam dot hopwood at blueyonder dot co dot uk  2005-07-29 11:58 -------
<http://gcc.gnu.org/ml/libstdc++/2002-02/msg00231.html> suggests defining
__GNUC_THREADMODEL__ to a string specifying the thread model.

-- 


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

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

[redi at gcc dot gnu dot org]

------- Additional Comments From redi at gcc dot gnu dot org  2005-07-29 12:40 -------
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.

-- 


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