Just checking on my understanding of the motivation for current library names, prompted by some work on updating Visual Studio IDE projects. I assume that Boost version, build (i.e. debug or release) and CRT specific names like: libboost_serialization-vc71-mt-1_32.lib, libboost_serialization-vc71-mt-gd-1_32.lib and similar are intended for binary distribution of libraries, where end user is not even expected to use bjam, but simply link with the library that she needs. OTOH, the executables link with version, build and CRT-linkage independent library names like: libboost_serialization.lib. I assume that this is done simply for build convenience, since library is nothing else but a packaged set of object modules, whatever name you give to it. In fact, when I build boost with VC++ 7.1, using command: bjam -sTOOLS=vc-7_1<RETURN> (VC++ 7.1 environment variables are assumed set at this point) in my "...bin\boost\libs\test\build\libboost_test_exec_monitor.lib\vc-7_1\debug\th reading-multi" directory I see both libboost_test_exec_monitor-vc71-mt-gd-1_32.lib and libboost_test_exec_monitor.lib libraries, and, as I would expect, they are exactly identical. The *only* case where both libraries are *not* built is for "runtime-link-static\threading-multi" build, where I see only version-specific library, such as libboost_test_exec_monitor-vc71-mt-sgd-1_32.lib, for example. Am I missing some deep rationale behind the build logic and names given to the libraries, or? Tony