regex depends on pthread library when boost is built with threading=single

[jdccdevel@…]

regex depends on pthread library when boost is built with threading=single

static_mutex.cpp uses the functions pthread_mutex_unlock and pthread_mutex_lock. This creates a dependancy on pthreads which should not exist when compiled with threading=single.

This is, in particular, a problem when static linking on AIX.

It appears that BOOST_HAS_THREADS is still being set when threading=single is set on the bjam command line.

[John Maddock]

I'm reassigning this because it's a Boost.Build issue, but... it might not be an issue at all:

As I recall after a long and agonising discussion, Boost.Build and Boost.Config were changed so that:

• threading=multi: changes whatever needs changing to make multithreaded builds work.
• threading=single: actually just uses the compiler's default options, if those happen to be thread-safe (ie the same as used for threading=multi) then BOOST_HAS_THREADS gets defined, and regex will use pthreads.

The rationale for this change was that most people actually want "one true binary" rather than a multitude of threadsafe / not threadsafe options. So on many platforms threading=multi and threading=single actually deliver the same thing. [aside - it would actually have been better IMO to have had 3 options - threading=multi, threading=default, and threading=single]

There is one other option, which is to build with BOOST_DISABLE_THREADS defined, which really will build a thread-unsafe binary - and of course that define would have to be set when you compile your source code as well.

I notice you don't mention which compiler you are using? Can you confirm whether there is any material differnce between how your compiler behaves with and without whatever command-line options are enabled by threading=multi (try building with bjam -d2 to see what options are being used)?

HTH, John.

[Vladimir Prus]

What I remember is that when gcc headers define _REENTRANT (or something else) unconditionally, as opposed to only with threading=multi/-pthread, then BOOST_HAS_THREADS gets set. And IIRC, this was deemed to be a gcc bug/feature. So, yes, more information is needed here.

[jdccdevel@…]

I am compiling with gcc version 4.2.4 on AIX.

I was able to remove the dependency on pthreads by building with BOOST_DISABLE_THREADS defined in boost/config/user.hpp

This is (thankfully) sufficient for my purposes for now.

I Definitely concur that threading=single is a highly misleading option in this case. If there needs to be two options, "threading=single" should renamed to "threading=default" as you implied above. Not being familiar with the internals of the boost build system, I would have expected threading=single to prevent the setting of the "BOOST_HAS_THREADS" define in all cases. However this is obviously not happening.

I understand that this is something of a unique case, as I cannot have a dependency on pthreads. However, If nothing else, I do believe that this should be more explicitly documented in the "bjam --help" documentation and elsewhere.

Jonathan