GCC 3.4 lpthread warnings
On the regression tests I'm seeing lots of warnings from gcc 3.4. For example: date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output: In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building." Lots of other libraries are seeing similar warnings with gcc 3.4. Date-time does nothing with threads so I believe based that I should just set define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows? Thanks, Jeff
On the regression tests I'm seeing lots of warnings from gcc 3.4. For example:
[snipped]
Lots of other libraries are seeing similar warnings with gcc 3.4.
Date-time does nothing with threads so I believe based that I should just
set
define BOOST_DISABLE_THREADS for the test cases to resolve this. But since I'm not certain of all the implications of this I thought I'd as for advice before proceeding. One specific question that comes to mind is do I need to limit the scope to gcc so I don't break MT, dll mode on Windows?
Darn, that would be me (again). We have a problem with gcc: thread support gets forced on in order to be consistent with libstdc++ (long story), and there was a user-request for a helpful message so that users would know that they *may* end up needing -lpthread. I agree that the message is a pain though, and Vladimir's point about warnings-as-errors is a good one. BTW I don't think that Jeff or anyone else should be required to mess with their Jamfiles to fix this; it's not their problem, it's a config/build one. My gut feeling is to just take the warning out for this release, longer term: Vladimir is there any macro that gets defined by the bjam build process, something like BOOST_BJAM_BUILD, so the code knows when it's being built by the bjam test system? Any other helpful suggestions welcomed.... John.
John Maddock wrote:
We have a problem with gcc: thread support gets forced on in order to be consistent with libstdc++ (long story), and there was a user-request for a helpful message so that users would know that they *may* end up needing -lpthread.
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
My gut feeling is to just take the warning out for this release, longer term: Vladimir is there any macro that gets defined by the bjam build process, something like BOOST_BJAM_BUILD, so the code knows when it's being built by the bjam test system? Any other helpful suggestions welcomed....
No, I don't know any. How would that help? I'm not sure if such macro can be easily added in Boost.Build v1. In V2 it's one-line change to top-level Jamfile, so I hope V2 will be ready to replace V1 after we've done with the release. - Volodya
We have a problem with gcc: thread support gets forced on in order to be consistent with libstdc++ (long story), and there was a user-request for a helpful message so that users would know that they *may* end up needing -lpthread.
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
Yep, but if -pthread is specified on the command line, then presumably the user really does want thread safe code :-)
My gut feeling is to just take the warning out for this release, longer term: Vladimir is there any macro that gets defined by the bjam build process, something like BOOST_BJAM_BUILD, so the code knows when it's being built by the bjam test system? Any other helpful suggestions welcomed....
No, I don't know any. How would that help? I'm not sure if such macro can be easily added in Boost.Build v1. In V2 it's one-line change to top-level Jamfile, so I hope V2 will be ready to replace V1 after we've done with the release.
I was just thinking out loud really, that maybe we could automatically suppress things like this whenever we're building with bjam, but you're right it doesn't really solve the issue. John.
John Maddock wrote:
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
Yep, but if -pthread is specified on the command line, then presumably the user really does want thread safe code :-)
Right. The current problem is that _REENTRANT is always defined by libstdc++ headers, so we can't use it to detect if user has specified -pthread. However, if boost/config.hpp is included before system headers and checks for _REENTRANT before including system headers on its own, it can reliably check if -pthread was specified. Of course, the requirements to include boost/config.hpp before everything else is a drastic one. - Volodya
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
Yep, but if -pthread is specified on the command line, then presumably the user really does want thread safe code :-)
Right. The current problem is that _REENTRANT is always defined by libstdc++ headers, so we can't use it to detect if user has specified -pthread. However, if boost/config.hpp is included before system headers and checks for _REENTRANT before including system headers on its own, it can reliably check if -pthread was specified. Of course, the requirements to include boost/config.hpp before everything else is a drastic one.
Sorry, I misunderstood you: that was what the fix to libstdcpp3.hpp was for: it checks to see if libstdc++ is multithreaded and then sets Boost to the same default. This results in consistent behaviour irrespective of what headers you include and in what order you include them, but at the possible expense of turning on threading support when you don't really need it. It's not ideal, but it's going to have to suffice for 1.33. John.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! On Monday 28 June 2004 17:10, John Maddock wrote:
I was just thinking out loud really, that maybe we could automatically suppress things like this whenever we're building with bjam, but you're right it doesn't really solve the issue.
Well, the warning appears in "End-User"-Code, too. So I had to remove the #warning from my CVS-Snapshot because I got this warning as soon as I use "boost/smart_ptr.hpp". And we do multithreaded builds as default, so Boost.config should have detected this... And we're not using bjam as our main build system. Just my .02€. Yours, Jürgen - -- * Dipl.-Math. Jürgen Hunold ! Institut für Verkehrswesen, Eisenbahnbau * voice: ++49 511 762-2529 ! und -betrieb, Universität Hannover * fax : ++49 511 762-3001 ! Appelstrasse 9a, D-30167 Hannover * hunold@ive.uni-hannover.de ! www.ive.uni-hannover.de -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA4rOGljbJ/LLrxrYRAlS7AKDW4pet4dFywjrjTujGK3Hy0RFKnQCgxjqk 0y52ylSfgt+M6U2XEctJ5S0= =PyBr -----END PGP SIGNATURE-----
Jeff Garland wrote:
date_time - test_greg_wstream - gcc-3.4.0-linux Compiler output:
In file included from /boost/head-regression/boost/boost/config.hpp:44, from /boost/head-regression/boost/boost/date_time/locale_config.hpp:19, from /boost/head-regression/boost/boost/date_time/compiler_config.hpp:14, from /boost/head-regression/boost/boost/date_time/gregorian/gregorian.hpp:19, from ../libs/date_time/test/gregorian/testgreg_wstream.cpp:10: /boost/head-regression/boost/boost/config/stdlib/libstdcpp3.hpp:33:7: warning: #warning "Boost threading support turned on, you may need to link against -lpthread unless you define BOOST_DISABLE_THREADS when building."
Oops! Looking at the code in question: #ifdef __GLIBCXX__ // gcc 3.4 and greater: # ifdef _GLIBCXX_HAVE_GTHR_DEFAULT // // If the std lib has thread support turned on, then turn it on in Boost // as well. We do this because some gcc-3.4 std lib headers define _REENT // while others do not... // # define BOOST_HAS_THREADS # warning "Boost threading support turned on, you may need to link against - # else # define BOOST_DISABLE_THREADS # endif #endif it seems the warning is *always* emitted, which is really bad, especially to folks like me who compile things with -Werror :-( May I suggest that at least this warning is not emitted when expicit BOOST_DISABLE_THREADS or BOOST_HAS_THREADS were specified by the user, so that I can have a way to kill the warning? - Volodya
May I suggest that at least this warning is not emitted when expicit BOOST_DISABLE_THREADS or BOOST_HAS_THREADS were specified by the user, so that I can have a way to kill the warning?
Just a small point the user should never really define BOOST_HAS_THREADS: although it will turn on Boost thread support, that doesn't mean that the compiler can actually produce thread safe code (for example gcc on one or two Unix platforms is incapable of producing thread safe code, even though all the underlying support, -lpthread etc is there). John.
John Maddock wrote:
May I suggest that at least this warning is not emitted when expicit BOOST_DISABLE_THREADS or BOOST_HAS_THREADS were specified by the user, so that I can have a way to kill the warning?
Just a small point the user should never really define BOOST_HAS_THREADS: although it will turn on Boost thread support, that doesn't mean that the compiler can actually produce thread safe code (for example gcc on one or two Unix platforms is incapable of producing thread safe code, even though all the underlying support, -lpthread etc is there).
Point taken. But it's actually does not matter how the macro is named: BOOST_HAS_THREADS, BOOST_ENABLE_THREADS or BOOST_I_AM_GOING_TO_LINK_PTHREADS, as long as I'm not stuck with the warning. - Volodya
On Wed, Jun 30, 2004 at 02:40:25PM +0400, Vladimir Prus wrote:
John Maddock wrote:
We have a problem with gcc: thread support gets forced on in order to be consistent with libstdc++ (long story), and there was a user-request for a helpful message so that users would know that they *may* end up needing -lpthread.
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
That's correct AFAICT, but does not really help. There's already too much code that includes system headers before any boost headers.
My gut feeling is to just take the warning out for this release,
Since the above mentioned user request came from me it's no surprise that I'd consider this a pitty. My programs are single-threaded most of the time and compiled without the `-pthread' flag. (However, I build my compilers with pthred support for the odd multi-threaded program.) Up to now I could use boost libraries "out of the box". You can imagine my surprise when I linked against a non-mt build of the boost test library and suddenly got linker errors due to missing symbols from the pthreads library. Even worse, it turned out that there were ODR violations because the test library and my application saw different definitions of shared_ptr. In the test library (that somehow includes string before the boost config.hpp), shared_ptr used pthread for locking while in my application dummy locks were used. It took me quite some time to figure out what was going wrong. My guess is that the intersection of boost and gcc 3.4 users will grow fast. If you don't implement some kind of warning (with #warning in the config headers or at least very prominently in the docs) then I assume the boost mailing list will see many problem reports abot this issue even though there's not much boost developers can do about it. And you also may turn away a significant number of potential users that don't have the time to investigate this problem. (I am speculating, of course, but this scenario seems plausible to me.) On Wed, Jun 30, 2004 at 02:28:47PM +0400, Vladimir Prus wrote:
John Maddock wrote:
May I suggest that at least this warning is not emitted when expicit BOOST_DISABLE_THREADS or BOOST_HAS_THREADS were specified by the user, so that I can have a way to kill the warning?
Just a small point the user should never really define BOOST_HAS_THREADS: although it will turn on Boost thread support, that doesn't mean that the compiler can actually produce thread safe code (for example gcc on one or two Unix platforms is incapable of producing thread safe code, even though all the underlying support, -lpthread etc is there).
Point taken. But it's actually does not matter how the macro is named: BOOST_HAS_THREADS, BOOST_ENABLE_THREADS or BOOST_I_AM_GOING_TO_LINK_PTHREADS, as long as I'm not stuck with the warning.
In my original request I asked that the warning only be emitted if neither BOOST_HAS_THREADS nor BOOST_DISABLE_THREADS is defined. I see why John Maddock does not want to test for a user defined BOOST_HAS_THREADS (it shouldn't be user defined in the first place). But then, how can a user express in config/user.hpp that he really wants to compile his sources with threading support? If you add a macro BOOST_ENABLE_THREADS (or whatever name) you can still generate an error in config.hpp if both BOOST_ENABLE_THREADS and BOOST_DISABLE_THREADS are defined or if BOOST_ENABLE_THREADS is defined but there seems to be no threading support by the platform. If none of these macros is defined, you can still default to the current behaviour (and raise a warning on a gcc 3.4 / linux platform). Regards Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
That's correct AFAICT, but does not really help. There's already too much code that includes system headers before any boost headers.
If we're in the same situation as Python, which requires "python.h" be included before any system headers, it's a damn shame. I don't understand all the reasons for this situation -- is it POSIX's fault? Can we get them to fix this? AFAICT it's almost impossible to formulate consistent rules for using libraries together now. If someone wants to use python and boost together, what should she do? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
That's correct AFAICT, but does not really help. There's already too much code that includes system headers before any boost headers.
If we're in the same situation as Python, which requires "python.h" be included before any system headers, it's a damn shame. I don't understand all the reasons for this situation -- is it POSIX's fault? Can we get them to fix this? AFAICT it's almost impossible to formulate consistent rules for using libraries together now. If someone wants to use python and boost together, what should she do?
No we're not in that situation: as of the current cvs state it doesn't matter what headers you include or in what order (as far as Boost is concerned anyway, I can't comment about Python), however if you are using gcc-3.4 then you may find threading support "always on" unless you define BOOST_DISABLE_THREADS. This is actually the same situation we had prior to the 1.31 release BTW. It's not ideal, but it is at least consistent, and once the gcc folks fix the libstdc++ setup, we can re-evaluate things again. John.
David Abrahams wrote:
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
That's correct AFAICT, but does not really help. There's already too much code that includes system headers before any boost headers.
If we're in the same situation as Python, which requires "python.h" be included before any system headers, it's a damn shame.
That's true.
I don't understand all the reasons for this situation -- is it POSIX's fault?
No, it's gcc's fault. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
Can we get them to fix this? AFAICT it's almost impossible to formulate consistent rules for using libraries together now. If someone wants to use python and boost together, what should she do?
She's out of luck, I'm afraid. We can only hope that gcc developers will fix this, and I don't know how we can affect the issue's priority... - Volodya
On Wed, Jun 30, 2004 at 09:25:56AM -0400, David Abrahams wrote:
Christoph Ludwig <cludwig@cdc.informatik.tu-darmstadt.de> writes:
BTW, I was told that if boost/config.hpp is included before any system headers, it will still be able to use _REENTRANT to detect if -pthread was specified on the command line.
That's correct AFAICT, but does not really help. There's already too much code that includes system headers before any boost headers.
If we're in the same situation as Python, which requires "python.h" be included before any system headers, it's a damn shame. I don't understand all the reasons for this situation -- is it POSIX's fault?
The first problem is that the gcc option `-pthread' isn't documented for linux / x86. If you search http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Option-Summary.html then "pthread" is found only among the RS/6000 and PowerPC options. It's therefore always some guesswork what you can expect from gcc if you compile with pthread support. In particular, it's not documented how you can *detect* pthread support. IIUC POSIX does not (implicitly or explicitly) require any special compiler flags when you compile C code that uses a pthread implementation. I am not even sure whether it is strictly necessary to use the `-pthread' flag if you compile and link such code with gcc or whether it it is mainly a convenience option. (The situation may be different for C++ code if, e.g., the EH code is affected by the pthread support. But POSIX ignores C++, doesn't it?) If I am correct then POSIX cannot require any means to detect *activated* pthread support. I rather think it is a QoI defect of gcc 3.4.
Can we get them to fix this?
If you look at the discussion of gcc PR#11953 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953) then it seems the gcc developers intend to restore the situation we had up to gcc 3.3.x where you could rely on _REENTRANT. That won't happen before gcc 3.4.2, though. Christoph -- http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html
The first problem is that the gcc option `-pthread' isn't documented for linux / x86. If you search http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/Option-Summary.html then "pthread" is found only among the RS/6000 and PowerPC options. It's therefore always some guesswork what you can expect from gcc if you compile with pthread support. In particular, it's not documented how you can *detect* pthread support.
IIUC POSIX does not (implicitly or explicitly) require any special compiler flags when you compile C code that uses a pthread implementation. I am not even sure whether it is strictly necessary to use the `-pthread' flag if you compile and link such code with gcc or whether it it is mainly a convenience option. (The situation may be different for C++ code if, e.g., the EH code is affected by the pthread support. But POSIX ignores C++, doesn't it?)
If I am correct then POSIX cannot require any means to detect *activated* pthread support. I rather think it is a QoI defect of gcc 3.4.
As far as POSIX is concerned then checking for _POSIX_THREADS in unistd.h is sufficient, and this probably is the case for C compilers, but as you say for C++ this is not the case. BTW _REENTRANT isn't standardised anywhere: it's just used informally by some Unix C/C++ compilers to indicate when thread safe code generation is turned on, which makes gcc's decission to define it in a header even more annoying. John.
participants (2)
-
Christoph Ludwig -
David Abrahams -
Jeff Garland -
John Maddock -
Jürgen Hunold -
Vladimir Prus