MSVC 2019

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

MSVC 2019

Boost - Dev mailing list
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'

It appears that compatibility with Visual Studio/MSVC 2019 has not been
worked out in 1.70 given its release date was so close to the release date
of Visual Studio 2019.
I also noted the the beta for 1.71 was closed.  Wondering if the beta fixes
this or is there a workaround or is this a user error?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
On 7/13/19 18:37, Cg K via Boost wrote:

>
> It appears that compatibility with Visual Studio/MSVC 2019 has not been
> worked out in 1.70 given its release date was so close to the release date
> of Visual Studio 2019.
> I also noted the the beta for 1.71 was closed.  Wondering if the beta fixes
> this or is there a workaround or is this a user error?
>

There will be a 1.71.0 beta shortly. I recommend that you give that a
spin when it is out and see how it works for your needs.

michael

--
Michael Caisse
Ciere Consulting
ciere.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list


> -----Original Message-----
> From: Boost <[hidden email]> On Behalf Of Cg K via Boost
> Sent: 14 July 2019 02:38
> To: [hidden email]
> Cc: Cg K <[hidden email]>
> Subject: [boost] MSVC 2019
>
> 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'
>
> It appears that compatibility with Visual Studio/MSVC 2019 has not been worked
> out in 1.70 given its release date was so close to the release date of Visual
Studio
> 2019.
> I also noted the the beta for 1.71 was closed.  Wondering if the beta fixes
this or
> is there a workaround or is this a user error?

I think you will need to compile the libraries yourself - you will only have the
1.41 in the prebuilt libraries.

https://www.boost.org/doc/libs/1_70_0/more/getting_started/windows.html

If you have both 14.1 and 14.2 compilers installed, you will need to adjust your
user-config.jam (or system) so that b2 only uses 14.2 (simpler)  

b2 toolset=msvc-14.2,

 or provide both so that you can built either or both.

b2 toolset=msvc-14.2,msvc-14.1

The *default* msvc version is the *first* in the .jam file.

Or wait until prebuilt 14.2 libraries are available.

HTH

Paul




_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
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.)

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
On Mon, 15 Jul 2019 at 02:42, Gavin Lambert via Boost <[hidden email]>
wrote:

> 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.)
>

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).

Another option is to adopt vcpkg, your Boost Build woes will be over.

degski
--
@realdegski
https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-penalty-intl/
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
[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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
On Tue, 16 Jul 2019 at 01:01, Stephan T. Lavavej <[hidden email]>
wrote:

> [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.
>

Thanks, for adding (and clarifying) the caveats.

degski
--
@realdegski
https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-penalty-intl/
"Anyone who believes that exponential growth can go on forever in a finite
world is either a madman or an economist" - Kenneth E. Boulding

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Jul 16, 2019 at 12:01 AM Stephan T. Lavavej via Boost
<[hidden email]> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
Nope! Sometimes you can get away with it.

STL

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

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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: MSVC 2019

Boost - Dev mailing list
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=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>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 <
[hidden email]> wrote:

> Nope! Sometimes you can get away with it.
>
> STL
>
> -----Original Message-----
> From: Olaf van der Spek <[hidden email]>
> Sent: Friday, July 19, 2019 2:55 AM
> To: boost <[hidden email]>
> Cc: Stephan T. Lavavej <[hidden email]>
> Subject: Re: [boost] MSVC 2019
>
> On Tue, Jul 16, 2019 at 12:01 AM Stephan T. Lavavej via Boost <
> [hidden email]> 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
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>

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