John Maddock wrote:
joaquin@tid.es wrote:
OK, understood. Then, we have the somewhat unfortunate situation that in GCC environments Boost.Build links / does not link Pthreads depending on whether the threading parameter is multi / single, whereas Boost.Config does not reflect this situation in any manner!
As most GCC environments (somebody correct me if I'm wrong) are nowadays multithreaded, would it make sense to change GCC Boost.Build bjam rules so that threading=simple results in BOOST_DISABLE_THREADS being defined?
Sigh... no, while that would no doubt fix a few tests, what users were asking for (and what we now build by default) is a single binary for gcc/*nix systems that can be used irrespective of whether they're using threads or not. In other words we want to fix the Boost ABI to be the same as the libstdc++ ABI, no matter whether a default threading-single build is done or not.
Hope this is making some sense, but I don't know what the correct solution is....
I don't know if the current solution is right. libstdc++ will work no matter if your application is ST or MT -- where "MT" application is defined as application that links to pthread and actually creates multiple threads. But I think it's result of explicit work. In particular: - ABI is the same in ST and MT builds - if application is not linked to pthreads, then libstdc++ will use dummy functions for synchronisation, with almost zero overhead. Boost, on the other hand, does not do anything special. The overhead of locking does not go away if application does not use threads. Therefore, it makes sense to control if that overhead exists -- by explicitly controlling if Boost should be built in ST or MT mode, as selected by 'threading' feature in Boost.Build or by -pthread command line option in gcc. Just always building in MT mode is easy, but I don't know if that's the best solution. - Volodya