Question: why are you manually linking when that is known is to error prone no matter how careful you are? Why not let auto-linking pick the correct variant for you?
Fair point: Frustration on a biblical scale. Post installation I fired up a VS2012 shell and built using b2 and the default options. B2 duly created the libs in /stage as here: U:\pkg\boost_1_55_0\stage\lib\libboost_system-vc120-mt-gd-1_55.lib Then I created an utterly vanilla Windows project in VS2012, added the relevant paths to the include and lib directories, hit F5 and got this: 1>------ Build started: Project: tcpproxy, Configuration: Debug Win32 ------ 1> tcpproxy_server.cpp 1>LINK : fatal error LNK1104: cannot open file 'libboost_system-vc110-mt-gd-1_55.lib' ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Now, I do *think* I know the cause(s) of the problem here: Superficially, the numbering 'scheme' bears no resemblance to either names of Visual Studio editions or the version number of the relevant C++ compilers. There was, for example, no VS2011. There was however a 10,12 and 13! More seriously there is a breaking of a long-standing contract that states that given a shell that contains a VS2012 environment, the build system should, under no circumstances, use a different version of the compiler to create libraries. Never. Ever. These issues remain, IMHO, a major bugbear for Boost. It has been entirely possible to have #include-only code for years. The original STL was a superb example. The code and all the care and thought that has gone into the Boost system itself is also a gigantic, and gigantically valuable, resource. Problem is that much of it becomes too hard to connect, and too brittle when connected. Given the multitude of compilation/link options even on Windows using the MSFT tools, it is all too easy to get an utterly impenetrable disconnect between boost user and the libraries. Worse, there is no canonical, shareable, method of ensuring that library builds match projects. Amply evident here I think. The fact that so much blood, sweat and tears has *then* had to go into a (borked and impenetrable) build system is really unfortunate. Try, for example, b2 toolset=msvc and see what you get. 2 final points: I am quite prepared to eat my hat if someone can disabuse me of these notions. You did ask :) VBR, Jerry