Re: [Boost-users] Sanity check please?: Boost 1_55_0 and building VS2012 static libs?

Subject: Re: [Boost-users] Sanity check please?: Boost 1_55_0 and building VS2012 static libs?
From: g4_at_[hidden]
Date: 2014-05-21 15:23:01

> 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