I have developed an application using Qt 5.2 which has be to be compiled in Visual studio 2008. But i found on the following link that the oldest MSVC compiler that can be used with Qt5 is MSVC2010.
Link
Is it possible to compile Qt 5.2 application with MSVC 2008 ?
Thank you for any pointers.
You will need one of three solutions:
1) Drop MS2008 and use a modern compiler
2) Use an older Qt that supports VS2008 (some Qt4 version)
3) Compile Qt5 with old compiler and hope the best
I would try to do 1) even if it means some effort. You should always try to stay up to date (and the longer you wait the more difficult it gets). If this isn't possible I would probably try 2) since it gives you an oudated but at least stable Qt. 3) is the worst solution at my opionion since anything could happen... without good chances to cleanly solve appearing compatibility issues.
As the http://download.qt-project.org/official_releases/qt/5.2/5.2.1/ (but also your link) shows there is no official package for Qt 5.2 with MSVC2008. However, this does not mean you should not try to compile it.
Just download the source from http://download.qt-project.org/official_releases/qt/5.2/5.2.1/single/ and try to compile it. I see in the mkspec directory an entry for win32-msvc2008 so in theory it should work, however I cannot guarantee that it will compile flawlessly.
But I am very curious how did you manage to
developed an application using Qt 5.2 which has be to be compiled in Visual studio 2008
Maybe you should upgrade your compiler to get the full benefits that come with it.
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.
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.
What are the different platforms/languages in which an app can be compiled and run on Windows without any prerequisites? I know of .NET but it requires the specific version of .NET to be present in the Windows installation.
C and C++, but Visual Studio defaults to dynamically linked library. Change the default to static and you will be fine.
That being said, ther are no compilers that come with windows. You must install a compiler to build the a program that will run everywhere after that. There are free version of the compiler in the Platform SDK and in mingw (Cygwin requires a dll).
If you are using Visual C++ as language and development tool, you may switch to Statically bound DLLs, which would produce larger binaries, but would run without any runtime-prerequisites. Visual C++ Runtimes are easily installable, can be distributed, or users may be asked to install them directly. If users are using Windows Update, they would anyhow get the latest VC runtimes.
Can I use new SDK directories that comes with VS2010 for VS2005 ?
I expect you can, but unless you need that specific version the simplest thing to do would be to download the latest Windows SDK instead:
Microsoft Windows SDK for Windows 7 and .NET Framework 4
This is more recent and can (IIRC) automatically integrate into VS2005.
If there is going to be an issue with this or with the VS2010 SDK then it will be because the .lib files are incompatible, e.g. through an object file format change or through a whole-program-optimisation intermediate representation change. However most if not all of the .libs in the SDK will just be DLL headers and so this shouldn't be an issue. (In the SDK release notes there is actually a link to a supported hotfix that improves compatibility between VS2005 and VS2008 objects but it sounds like VS2005 SP1 will usually be enough.)
There's a slim chance that the header files might not work (or might assume a different set of default defines) but in general the Windows header files are very careful with defines and version testing that I doubt this would be an issue.
If you're asking if you can use ATL + MFC from the later version then I think this is less clear cut, and may require a recompile of their sources in the older compiler. In that case I think your best option might be to upgrade to VS2010 if that's possible.