The build script for the thread library had some short-comings: *) Incorrect handling when <threading>single was specified on the command line. *) Annoying unrelated messages even when build boost libs, that had nothing to do with the thread lib. *) Name clashes when trying to build the thread lib for win32 and pthread at the same time. I addressed these issues with a new Jamfile, without changing the default behavior known from version 1.34: 1) Even when requesting <threading>single on the command line (or in Jamroot) the requirements of <threading>multi will now be honored correctly. (This is boost policy.) 2) It is possible to request a build of the threading lib for a specific api. The feature <threadapi> with allowed values "win32" and "pthread" is used for this. On the cmdline e.g. this is bjam --with-thread threadapi=pthread . (I removed the hyphen from the name on Volodyas recommendation.) 3) There is the concept of "native" api. On windows (more exactly the result of os.name is NT) this is win32, else pthread. The resulting library has the usual name "boost_thread" for the native api. The non native api is tagged with the api. E.g. the request bjam --with-thread install threadapi=win32,pthread will result in libraries booot_thread* and boost_thread_pthread*. (No more duplicate name errors.) 4) The information messages telling, that pthread is not available will only be emitted when really trying to build with pthread. I hope this will be less annoying to users that are not interested in pthread api. 5) The paths to the installed pthread lib now can be set in one of three places: environment, user-config.jam and site-config.jam. Thank you for attention, Roland aka speedsnail