From: Cg K (kaucher_at_[hidden])
Date: 2019-07-27 18:22:18
As a followup....
I have been able to compile boost_1_71_0_b1_rc1 using VS 2019.
I compiled following this youtube video
opened up a developer command prompt
Ran .\bj2 link=shared
It appears that all compiled successfully and
the libs and DLLs are in
I then followed this youtube video
<https://www.youtube.com/watch?v=CH_YZ2bePPM&t=42s>to build a simple
boost_example using VIsual Studio 2019 and get the following linker error
when building a Release version in 64bit.
1>------ Build started: Project: Boost_example, Configuration: Release x64
1>Please define _WIN32_WINNT or _WIN32_WINDOWS appropriately. For example:
1>- add -D_WIN32_WINNT=0x0601 to the compiler command line; or
1>- add _WIN32_WINNT=0x0601 to your project's Preprocessor Definitions.
1>Assuming _WIN32_WINNT=0x0601 (i.e. Windows 7 target).
1>LINK : fatal error LNK1104: cannot open file
1>Done building project "Boost_example.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
I searched the for the linker error on the web and came up and noted that
in a prior post <https://github.com/dividiti/ck-caffe/issues/121>
there was a typo presumably in the source code that was the problem. Also
the error may have been caused by not setting up the additional include and
library directories in the project property sheet. Respectively, these
I did this. I did not set the BOOST_ROOT environment variable as I
understand that it has been deprecated.
The lib directory includes a file
Any thoughts? New User I/O error or something in RC1?
On Fri, Jul 19, 2019 at 2:05 PM Stephan T. Lavavej via Boost <
> Nope! Sometimes you can get away with it.
> -----Original Message-----
> From: Olaf van der Spek <ml_at_[hidden]>
> Sent: Friday, July 19, 2019 2:55 AM
> To: boost <boost_at_[hidden]>
> Cc: Stephan T. Lavavej <stl_at_[hidden]>
> Subject: Re: [boost] MSVC 2019
> On Tue, Jul 16, 2019 at 12:01 AM Stephan T. Lavavej via Boost <
> boost_at_[hidden]> wrote:
> > There's a potential issue with doing that. Binary compatibility between
> the 2015, 2017, and 2019 toolsets comes with a couple of restrictions: no
> LTCG (which is a non-issue here), and the final link must be performed by a
> toolset that's as new as (or newer than) all of the object files and
> libraries being linked. For example, you can't take VS 2019 16.1 (v142)
> compiled libraries, and perform a final link with VS 2015 RTM (v140). And
> in practice, I am aware of at least one build break that can be encountered
> when attempting this (as we added a vectorized implementation of
> std::reverse that requires separately compiled support to be dragged in
> during the final link).
> Isn't this (no forward compatibility) detected and enforced by the linker?
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk