Subject: Re: [boost] RC2 / VS2017 - shared libraries questions
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2017-08-15 17:32:39
[alanbirtles2]
> VC 2015 and 2017 share the same ABI and runtime libraries
Correct.
[Roger Leigh]
> Note that it's conditionally true. VS2017 can use the v140 toolset from VS2015.
> But you can also choose to use the v141 toolset which is *not* compatible.
Incorrect.
The complexity of our versioning story is admittedly a freight train colliding with a dumpster fire orbiting a supernova. Here's the simple form:
* There are two IDEs, VS 2015 (which was updated several times) and VS 2017 (also updated several times so far).
* Each IDE shipped with a corresponding toolset. VS 2015 shipped with toolset v140 (compiler 19.00) and VS 2017 RTM shipped with toolset v141 (compiler 19.10).
* The VS 2017 IDE which ordinarily uses the v141 toolset has the ability to install and use the v140 toolset, without the VS 2015 IDE itself being installed.
* From now on, I will mostly ignore the IDEs and focus on the toolsets (and I will try to be careful to use toolset/compiler versioning - through metonymy I usually refer to toolset versions by their corresponding IDE versions but that isn't a good idea here).
* The v140 toolset (compiler 19.00) uses the Universal CRT in Windows (ucrtbase.dll) and additional DLLs that are part of the VCRedist: vcruntime140.dll, msvcp140.dll, etc.
* We updated the v140 toolset a few times, fixing bugs and (notably) adding features. (These shipped alongside the VS 2015.1, 2015.2, and 2015.3 IDEs.) All updates were binary-compatible and updated the DLLs in-place. This was true even for major updates like fixing the dreaded iostreams floating-point performance regression.
* The v141 toolset (compiler 19.10, originally) still uses ucrtbase.dll, vcruntime140.dll, msvcp140.dll, etc. It is binary-compatible with the v140 toolset, and objects/libs/DLLs can be intermixed freely. That said, it is still a good idea to compile everything consistently with the latest toolset so you receive all correctness/performance fixes, but mixing versions won't trigger crashes or other misbehavior.
* We just updated the v141 toolset, which can be identified by its compiler version (the VS 2017 15.3 IDE update installs a new v141 toolset with compiler 19.11). Again, we've added new features while preserving bincompat.
We're going to a LOT of trouble to preserve binary compatibility, so we hope it is useful. (We are having to be careful when updating the STL - any header change essentially triggers an ODR violation when object files are mixed-and-matched but there are innocuous ODR violations and poisonous ODR violations, and we know how to tell the difference.)
STL