I've been trying to build Boost.Thread and a number of other libraries for use in the software in the company where I work, and was only stopped by a number of STLport related problems. We already use header-only boost libraries for many years, and now would like to start using other boost libs. The main problems are: 1. We use unchecked STLport variant (i.e. without __STL_DEBUG). Unfortunately, Boost is not compatible with this mode, although a fix to add this mode is only a few lines of code in boost build. When I added this mode and recompiled boost, everything ran without any noticeable problems. I think it is worth adding this mode to boost build so that developers wouldn't have to patch boost build to add this mode. 2. It is very usefull that compiled boost libraries embed version number and different compile time options in their names. Unfortunately, STLport version is not embedded in their names (only 'p'). This creates a problem where two executables compiled against different STLport versions try to use the same Boost.WhateverLibrary dll. Are there any reasons not to embed STLport version number into boost library names? 3. A separate issue with Boost.Threads, where _sntprintf is called in boost_error in read_write_mutex.cpp, even when building with STLport, which does not have _snprintf. Also, there is bug in boost_error, which wrongly assumes that _sntprintf zero terminates the resulting string. I also wrote a patch to fix this problem. Is there any way to merge it into Boost.Thread? I understand that we could solve these problems either by not using STLport, or by changing the way we use it, but unfortunately, this is next to impossible for us, as we have a large software suite which is built and supported this way for years. Also, I think other developers would benefit if Boost provided workarounds/solutions for these common STLport problems. -- Valentin Samko http://val.samko.info