Hello Szymon and thanks. That, of course, hits the nail right on the head. The macro was defined out-of-view in the properties editor! From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Szymon Gatner Sent: 21 May 2014 16:52 To: boost-users Subject: Re: [Boost-users] Sanity check please?: Boost 1_55_0 and building VS2012 static libs? Most likely you main project has _SECURE_SCL=0 defined but BOOST was build without it. Use it when building BOOSt with b2 2014-05-21 16:51 GMT+02:00 <g4@novadsp.com>: Revisiting Boost after a long absence. Any thoughts on the following problem(s)? W7x64 with VS2008,2010,2012 and 2013 installed. VS2012 preferred for regular use. Built with boostrap and b2 b2 -link=static -runtime-link=static -toolset=msvc-11.0. I compile a debug test app with /MTd and attempt to link with libboost_system-vc110-mt-gd-1_55.lib which is the only library close to matching the ABI tag specified here : http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#id46 Ensuing link errors are: 1>libboost_system-vc110-mt-gd-1_55.lib(error_code.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in tcpproxy_server.obj 1>libboost_system-vc110-mt-gd-1_55.lib(error_code.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MT_StaticRelease' in tcpproxy_server.obj 1>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library Many thanks. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users -- Szymon Gatner Bravasoft / The Lordz Games Studio Twitter: @sgatner

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

True, but something of a diversion :) . B2 does not do the right thing when run in a shell configured for a specific version of VS, nor is this 'linkage' between 'versions' and official Visual Studio releases documented (say) here: http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html

I believe that Boost.Build is designed to ignore as much as possible of

Hello Lars the environment it happens to be in, so that you can provide particular versioned toolsets to it > and it'll Do The Right Thing. But does it respect the environment settings if run in a shell set up for VS2012 when 2013 is also present? Further to that , we also have straight-forwardly wrong behaviour exhibited by B2 when you pass it a non-existent tool-chain name. Like msvc in my example. It still builds ...

patches.

Fair enough. I am game. How do I do this? VBR. Jerry

-----Original Message----- From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jürgen Hunold Sent: 22 May 2014 20:41 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Sanity check please?: Boost 1_55_0 and building VS2012 static libs?

Please note the missing "-" on the feature definitions and toolset. Yes, it is unfortunate that b2 has three different option types targeting the different build system levels, but that is all documented. And the modular concepts makes it quite hard to detect "wrong" options.

B2 is indeed the Outer-Mongolia of computer 'languages'. It would be difficult to devise a more confusing 'syntax'. And I don't think it is very helpfully documented - we need 'B2/Bjam and Boost for Dummies'. As a result Insanity Rules OK. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 01539 561830

Worth a double-check.

I did. Several times before I posted. If you have the time repeat, precisely, the steps I outlined and you will get a bad build with 1_55_0. BR. Jerry.