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