Re: [jamboost] Re: Single-thread builds on GCC >= 3.4.0

From: John Maddock (john_at_[hidden])
Date: 2005-01-21 06:04:20

> Hmmm, wasn't the same true for GCC < 3.4.0? AFAICS the only thing that
> has changed is that there is no longer a safe way to detect whether the
> user requested an MT or ST build on the compiler command line. Instead,
> MT-ness is discovered through a define in std headers that the compiled
> code includes.
>
>> For now I believe
>> it's safer to make Boost "always thread safe" with gcc 3.4.
>
> Even when the user explicitly requests ST with <threading>single on the
> bjam command line? Sure, a user can compile a boost lib with
> <threading>single and then use that lib from code compiled normally
> (without bjam), which would presumably lead to a disaster. However,
> (s)he could have done the same with GCC < 3.4.0, right?

Let me try and explain:

Pre gcc 3.4:

1) A default Boost library build (no threading options specified) would link 
correctly to a program compiled with gcc in it's default settings (threading 
would be turned *off* in both).

2) A multithreaded Boost lib would link correctly with a program explicitly 
compiled with threading turned on (with -pthread or whatever).

Post gcc 3.4:

1) A default Boost library build (no threading options specified) would link 
correctly to a program compiled with gcc in it's default settings (threading 
would be turned *on* in both).

2) If threading support is explicitly turned on, it has no effect (because 
it's on already).

The drawback now is that there is no single threaded mode unless:

a) you compile gcc with threads disabled, but lets not go there!
b) you define BOOST_DISABLE_THREADS in both the library and application 
build.

Now lets try your proposal, with <threading>single defining 
BOOST_DISABLE_THREADS:

1) A default Boost library build (no threading options specified) would 
*not* link correctly to a program compiled with gcc in it's default settings 
(threading would be turned *on* in the application, and *off* in the lib). 
The user would have to "know" to define BOOST_DISABLE_THREADS in their 
application.

2) If threading support is explicitly turned on, it's safe and the same as 
before.

My problem with this is that (1) is what 99% of people actually do in 
practice.

BTW, I have suggested before on this list that the way to solve this, is to 
have three thread modes:

A) Threading forced on.
B) Threading forced off.
C) Don't care, just do whatever the compiler and standard library do by 
default.

Option (C) would really be a symlink to one of the other two, and would be 
the one with the unmangled name (no threading suffix). The way the toolsets 
are currently set up is to really offer (A) and (C), since that matches what 
the headers do internally.

John.