Some libraries are available to download as pre-compiled binaries, usually in specific architecture (x32 or x64) but I have also noticed that some pre-compiled binaries are splitted based on visual studio version, for example: vc17_x64. Let's assume that I use visual studio 2019. Does it mean that I have to use binaries precompiled for vc2019 or build a library from source when apropriate version is not available ? It's not clear for me because some pre-compilied binaries don't contain information about visual studio version.
If a pre-compiled library has Visual Studio version info you should use that version of Visual Studio to work with the library. This is not always the case though, as often enough happens that an older (with respect to VS version) library contains code that is a subset of the newer VS's header and runtime SDK files (.NET, C/C++, Windows SDK, etc). The other way around, when the library is newer can also work but it's far less frequent. You can try, if it doesn't work for your particular library and VS version then you should consider matching versions, rebuilding not always works for the same reasons of code changes.
If a library doesn't contain VS version info then it's reasonable to assume that it's portable/compatible up to operating system (Windows, Linux, etc) and programming language version (C++ 11, C++ 14, C# 7, C# 8, etc). However, VS version comes into play here as well, not every VS runs in every Windows, neither it supports the same runtimes, SDKs, and language(s) version. You should always check the library documentation for recommended working environment, if this info doesn't exist then it's trial and error and/or community consulting.
Related
We are currently using CUDA on windows which requires MS C++ Build tools installed. With every new version of the CUDA toolkit it happens that newer versions of Visual Studio are not supported. That's why we are using the MS build tools seperately so that the VS version doesn't matter.
Since its hard to guide our developers to install the right CUDA and MSVC version we have packaged it into NUGET packages so that the toolkit (especially NVCC) is in a defined version and location. Additionally we wanted to do this with MSVC but we couldn't find a good solution since the installer obviously does modifications on several places that we don't know.
Is there any good way to get the MSVC tools portable so that we can simply drop it into a folder and put the right pathes?
NVCC doesn't support GCC, otherwise I would have gone with this.
TL;DR - The MS docs state that binary compatibility between VS2015 and VS2017 libs is one-way, while I'd assumed it is necessarily two-way. Where's the catch?
First, for background:
Any MSVC++ built libraries are officially binary compatible between VS2015 and VS2017.
Specifically, you can use your VS2015 C++ app with the MSVCRT140 version from 2017. (VCRedist backwards compat)
The official documentation site states a confusing restriction.
Background / related Questions:
Is Visual-C++-2017 binary compatible with VC++-2015?
Questions about "Binary Compatibility between Visual Studio 2015 and Visual Studio 2017"
Binary compatibility between VS2017 and VS2015
The confusing restriction I find is:
There are two exceptions to this rule. Binary compatibility is not guaranteed in these cases:
...
When consuming libraries built with a toolset whose version is greater than the toolset used to compile and link the application. For example, a program that is compiled and linked with compiler version 19.12 can consume libraries that are compiled with 19.0 up through 19.12.
This caveat is, IMHO, both technically sloppy and confusing. What would the technical reason be for that?
I say it's sloppy because it is incomplete, because the interface between an executable and a DLL is pretty syymetric, but this bullet only covers "the application".
Specifially, and assuming all modules are built against the dynamic CRT version and this dynamic CRT version is the newest version available, I see the following combinations where binary compat is an issue:
my_2017.exe <-> my_2015.dll -- seemingly supported
my_2015.exe <-> my_2017.dll-- seemingly unsupported
my_2017.exe <-> my_2015.dll <-> my_2017_x.dll -- what now, in which "direction" is this supported btw DLLs?
Since binary compat - purely from the binary/interface perspective - must run both ways, I don't quite see where we suddenly could get an incompatibility here: API calls can go both ways (callbacks etc.), objects "move" both ways, even the order of DLL loading can be mixed.
This is an important point IMHO, as it means the binary compatibility as stated is severly limited:
If my application want's to consume any VC14* compiled library, I "officially" still must make sure that my application is built with the "newest version".
On the other hand, if don't build an "application", but have a DLL, I can seemingly consume any other VC14* DLL and be compatible?
With the VCRedist, we have exactly the case that is seemingly unsupported, namely we are allowed to consume a VC2017 library (CRT in this case) from a 2015 app!
Question
So, why(!) is this limited in the way it is, and how does it relate to inter-dll dependencies and also the inverted(!) CRT-dll version requirement.
Microsoft has since updated their docs, the relevant section of the current version of https://learn.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017 reads:
C++ Binary Compatibility between Visual Studio 2015 and Visual Studio 2019
...
When you mix binaries built with different supported versions of the MSVC toolset,
the Visual C++ redistributable that your application runs on cannot be older
than any of the toolset versions used
to build your app or any libraries it consumes.
The diff is at https://github.com/MicrosoftDocs/cpp-docs/commit/a505dccfb31eb49c2ffece4dabd24a0a61b1fcb3#diff-d488b4c71be450b2a39cdce495c229bf
There is no direct GitHub/MS-Docs issue for this, but this limitation makes a lot more sense: It just talks about the compatibility requirements of the redistributable, and requiring a VC runtime version that is at least as current as the newest module in use.
This, of course, can make sense, as this is not only pure binary compatibility.
Of course, what I said in the question still is valid: Any (old) VS2015 application must be compatible with the (new) VS2019 redistributable, so I guess all the interface surface that VCRedist-VC14.0 ever exposed should be binary compatible.
Is there any compatibility matrix as to what Visual Studio Versions (Say, ranging 2005 - 2017) are compatible with which Windows SDK Versions?
Should any Windows SDK be fully compatible with "any" C++ compiler, or are the different Windows SDK versions bound to certain compiler versions?
For example(!), we have a legacy C++ application that is still compiled with VS2005. We found that we'd like to use GetDpiForMonitor from this application. But to use this function, would require to use the headers+libs from at least an SDK supporting Windows 8.1 (e.g. the 8.1 SDK headers at C:\Program Files (x86)\Windows Kits\8.1\Include\um)
Generally, should a developer expect to be able to switch to a newer Windows SDK version without upgrading his compiler / Visual Studio?
Please refrain from suggesting to upgrade VS: This question tries to establish what you should do when upgrading VS is not an option for now, but you want to use stuff from (and depend on) functionality only available in newer Windows (SDK) versions.
concerning the "compatibility matrix": I don't think anybody made the effort to up to create one, also I'm not sure if this is really needed.
Rule of thumb: those API headers don't change quite often, and when they do, they are usually pretty much backward compatible.
The tricky part may be to teach your older VS to get along with a new SDK, you may need to change the VC+ include/source/lib directories for your solution/project manually.
(if it complies & links in your old VS, you should be fine)
The project I'm currently working on as an intern uses a number of 3rd party libraries (libCURL, OpenSSL, and others). I've noticed that there are a number of versions of the third-party .dlls used by the project, a developer selects which one they want to use depending on what version of Visual Studio they are developing in.
My task is to upgrade two of the libraries to a newer version (libCURL and OpenSSL). One way to do this is to build the libraries from the source files and then replace the old files with the new ones. This is what I want to do, as I think I'd learn more by doing that rather than using pre-built binaries.
My question is, what special thing do I need to do during the build process to make these two libraries work with Visual Studio 20XX? Is it as simple as building the libraries using the Developer Command Promp for Visual Studio 20XX? Alternatively, if I followed the official guides to build one of the libraries for Windows x64 (which is the bitness of the Windows I'm running), presumably the resulting files wouldn't work in Visual Studio 20XX? Why not? What are these "generic-ly built" versions of a library used for?
I'm kind of lost with all these SDK windows versions.
For instance, I installed vs2013 on windows8.1, and I (also) need to link my apps against vs2008 runtime (platform toolset).
Should I install the whole VS2008 too or just the API. In the last case, what SDK do I have to install ?
You are talking about two very distinct things. The Windows SDK only covers the declarations and libraries that you need to make winapi calls. SDK v8.1 is suitable to target any modern Windows version since Vista, you select the Windows version you want to target by setting the _WIN32_WINNT macro. Note that XP requires an older SDK version, v7.1 is the last one that's still suitable and selected by setting the Platform Toolset to v120_xp.
The runtime libraries are a pure implementation detail of Visual Studio C/C++ projects and completely unrelated to the SDK. When you build such a program on VS2013 with the /MD compile option then it will have a dependency on msvcr120.dll, possibly msvcp120.dll and others. These DLLs implement the C runtime library and the C++ standard classes. And possibly MFC, ATL, OpenMP and AMP if you use those libraries.
If you still have a dependency on the VS2008 version of those libraries then you are liable to have a Really Big problem. You can obtain the release versions of those DLLs from the redist installer you can download from Microsoft. Having a dependency on the debug version requires having VS2008 installed on your machine. But having trouble linking the program and misery at runtime is highly indicated, the runtime libraries changed a great deal between VS2008 and VS2013 thanks to the new C++11 language standard. Having more than one CRT in a program is in general liable to cause lots of trouble.
You need to strongly pursue getting the library that still has the VS2008 dependency rebuilt. Contact the owner of the library if necessary to get an update.