On 15/07/2019 01:32, Paul A Bristow wrote:

...

I recently installed Visual Studio 2019 and then Boost and Quantlib. I tried to compile Quantlb with the precompiled 1.70 boost. I go the error message: LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework- vc142-mt-gd-x64-1_70.lib' [...] I think you will need to compile the libraries yourself - you will only have the 1.41 in the prebuilt libraries.

Another option is to ensure that the v141 toolset is selected in all of your VS2019 projects. (This will of course use the older compiler, which may have its own caveats.)

[degski]

Or just rename the libs so they have the expected name. vc140, vc141 and vc142 are ABI-compatible AFAIK (and I know from good source vc142 is not gonna break that).

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). This binary compatibility allows application developers to upgrade their toolsets without blocking on all of their separately compiled libraries upgrading to the same toolset. It is specifically not intended to allow separately compiled libraries to upgrade their toolset beyond what their consuming applications are ready for. STL

On Tue, Jul 16, 2019 at 12:01 AM Stephan T. Lavavej via Boost 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? -- Olaf

As a followup.... I have been able to compile boost_1_71_0_b1_rc1 using VS 2019. I compiled following this youtube video https://www.youtube.com/watch?v=_BBJS2UXu2Q. Essentially, I opened up a developer command prompt Ran bootstrap.bat Ran .\bj2 link=shared It appears that all compiled successfully and the libs and DLLs are in C:\Users\xxxx\Desktop\lib\boost_1_71_0_b1_rc1\boost_1_71_0\stage\lib I then followed this youtube video https://www.youtube.com/watch?v=CH_YZ2bePPM&t=42sto 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>Boost_example.cpp 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 'libboost_date_time-vc142-mt-x64-1_71.lib' 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 directories are: C:\Users\xxxx\Desktop\lib\boost_1_71_0_b1_rc1 C:\Users\xxxx\Desktop\lib\boost_1_71_0_b1_rc1\boost_1_71_0\stage\lib 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 boost_date_time-vc142-mt-x64-1_71.lib' but not libboost_date_time-vc142-mt-x64-1_71.lib' 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 < boost@lists.boost.org> wrote:

Nope! Sometimes you can get away with it.

STL

-----Original Message----- From: Olaf van der Spek Sent: Friday, July 19, 2019 2:55 AM To: boost Cc: Stephan T. Lavavej Subject: Re: [boost] MSVC 2019

...

There's a potential issue with doing that. Binary compatibility between

On Tue, Jul 16, 2019 at 12:01 AM Stephan T. Lavavej via Boost < boost@lists.boost.org> wrote: 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?

-- Olaf

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost