Folks, I've finally found the cause of a problem that has been tripping us up for some time. We have a Windows application that we build for IA32 and x64. Naturally the IA32 version links against 32-bit import libraries and the x64 64-bit import libraries. But here's the rub: Boost generates output binaries with the same name for both platforms: bjam -sTOOLS=vc-8_0 bjam -sTOOLS=vc-8_0-amd64 both result in boost_serialization-vc80-mt-gd-1_33_1.lib boost_serialization-vc80-mt-gd-1_33_1.dll being created (among other things). Now because the Windows loader simply searches the PATH for the first DLL that matches the name of the import library, an x64 application linked against the x64 import library for Boost Serialization might load the IA32 version at runtime. Most other tool vendors solve this one by attaching a 'x64' suffix to the import and DLL filenames. However, despite what the Boost Build documentation says, the tool name "vc-8_0-amd64" is not used when building the DLL file name. We get stuck with the same filename for both platforms. Simply rename the files? Nope, the binary import library contains decorated names prefixed with the DLL name. The best fix would be to make bjam do the right thing: boost_serialization-vc80-amd64-mt-gd-1_33_1.lib boost_serialization-vc80-amd64-mt-gd-1_33_1.dll Am I missing something here? Thanks in advance, Terence