John Maddock
joaquin <at> tid.es wrote:
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.
What does defining/not defining BOOST_DISABLE_THREADS have to do with the Boost ABI? If currently the only effect of selecting threading=multi/single is whether Pthreads is linked/not linked, then the macro just reflects this into the world of Boost.Config. Is by chance BOOST_HAS_THREADS affecting the lib suffixes used in autolinking mode? If so, maybe the solution is to just adjust the autolinking in Linux appropriately. Sorry if I'm missing something obvious here --I'm sure I am :) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo