Subject: Re: [boost] RC2 / VS2017 - shared libraries questions
From: Stephan T. Lavavej (stl_at_[hidden])
Date: 2017-08-15 17:32:39
> VC 2015 and 2017 share the same ABI and runtime libraries
> 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.
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.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk