Re: [boost] Re: GCC 3.4 lpthread warnings

From: Christoph Ludwig (cludwig_at_[hidden])
Date: 2004-06-30 07:23:02

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