I just have installed on a clean windows 10, visual studio 2015 and Qt Creator 5.5...I have some source code that depend on some libraries (lib) files which I believe were compiled using msvc2012.
The Qt can not compile my project and always complains that selected compiler can not compile for Qt 5.5...I have spent hours on this but still no success...Would someone kindly tell me what should I do? Here is some photos of my Qt build options:
Visual C++ doesn't maintain binaries compatibility between versions, this means that you'll need to use the same Visual Studio version with all the libraries that are exposing C++ functionality (libraries that expose only a C interface can be used with different compiler version).
So you have 2 options:
1) install and use Visual Studio 2012, download and install a Qt version that is built with Visual Studio 2012 (Qt 5.5.0 for Windows 32-bit (VS 2012, 587 MB) ) Note that for VS 2012 there are only 32bit binaries available (if you want x64 you need to build Qt yourself)
or
2) if you want to use Visual Studio 2015, you'll need build Qt yourself with Visual Studio 2015, since there are no already built Qt binaries for Visual Studio 2015. And depending on how the other library is written you might need to also build that with Visual Studio 2015.
Related
As I read this article, it is enough to download most recent MSVS 2022 and then install toolset C++ Windows XP Support for VS 2017 (v141) tools [Deprecated].
After that in Visual Studio inside project properties I set this toolset. According to linked article it is enough to compile C++ app with XP support.
But after my .exe file is created if I run it on XP 64-bit SP2 then it shows error that CompareStringEx function is not found in KERNEL32.DLL.
Hence it appears that it is not enough to use this toolset. Something else is needed.
In some other places I see that one needs also to add define /D_USING_V110_SDK71_ when compiling and option /SUBSYSTEM:CONSOLE,5.01 when linking. In my project properties I also tried to add this two options, but still CompareStringEx is inside import table of final application.
As suggested by #BenVoigt, I did defines /DWINVER=0x0502 /D_WIN32_WINNT=0x0502. Also set C++ standard to /std:c++14 (I would set C++11 but this MSVS version allows to set only C++14 at minimum). Still some non-XP symbols remain in final EXE like InitializeSRWLock that is possibly used by C++11's std::mutex in my code.
Does anyone know everything what is needed in order to compile fully XP-compatible application?
Update. I managed to build working XP application by doing things above plus setting C++ CRT runtime to Multi Threaded DLL, i.e. using dynamic DLL linkage of CRT. Also as suggested by #ChuckWalbourn (down x86 or x64 redists), I downloaded older version of msvcp140.dll.
But it is very important for my project to have statically linked runtime (C++ CRT), i.e. use Multi Threaded value for Runtime field in project properties. Only if it is REALLY not possible only then I will use DLL CRT. Until then solution about how to link CRT statically are welcome, of course to produce XP-compatible EXE.
TL;DR For Window XP VC++ REDIST support, install https://aka.ms/vs/15/release/VC_redist.x86.exe on your Windows XP system
-or-
if you are doing "side-by-side application local deployment", then use the DLLs from C:\Program Files\Microsoft Visual Studio\2022\<edition>\VC\Redist\MSVC\14.16.27012\x86\Microsoft.VC141.CRT.
If you want the latest bug fixes to the CRT, you can also download the REDIST for VS 2019 (16.7) per the link on Microsoft Docs.
For Windows XP targeting, you use the v141_xp Platform Toolset installed by Visual Studio (VS 2017, VS 2019, or VS 2022) which is the latest VS 2017 (v141) C++ compiler using an included Windows 7.1A SDK.
Make sure you have installed (for VS 2022) the following individual components since you are using MFC:
Microsoft.VisualStudio.Component.WinXP: C++ Windows XP Support for VS 2017 (v141) tools [Deprecated]
Microsoft.VisualStudio.Component.VC.v141.x86.x64: MSVC v141 - VS 2017 C++ x64/x86 build tools (v14.16)
Microsoft.VisualStudio.Component.VC.v141.MFC: C++ MFC for v141 build tools (x86 & x64)
If you are doing DirectX development, be sure to read this blog post as well for various implications of using the Windows 7.1A SDK.
For deployment to Windows XP, you can install the latest VS 2017 Visual C++ REDIST or use VS 2019 Visual C++ up to VS 2019 (16.7). After that the REDIST DLLs themselves are not compatible with Windows XP.
On your development system with VS 2022 installed, you are going to have a newer set of Visual C++ REDIST files which are binary compatible with your v141_xp Platform Toolset built EXE, but those VC++ REDIST DLLs are not compatible with Windows XP.
IOW: If you look at a dumpbin /imports of the 14.30 (v143 version), 14.29 (v142 latest version), and/or 14.16 (v141 latest version ) copies of msvcp140.dll you will see different imports. The msvcp140.dll sitting in your C:\windows\SysWOW64 folder is going to be the 14.30 version.
I am programming in C++ on Windows using Visual Studio 2019 and Qt.
I am using a library created by another programmer that depends on a 3rd party .dll that in turn depends on msvcp140.dll and vcruntime140.dll.
I have installed Platform Toolset Visual Studio 2015 (v140).
However I do not wish to link with this since it seems to prevent me from using ISO C++17 Standard (when I select Platform Toolset="Visual Studio 2015 (v140)" the C++ Language Standard option is removed).
Is it safe to mix Platform Toolset: "Visual Studio 2015 (v140)" and "Visual Studio 2019 (v142)"?
The other programmer claims so. He has made sure that his API does not use any std class (e.g. string) as input or output.
Is this sufficient or is there something else I have to think of?
As Hans Passant says, you can continue to use V142 for your VS2015 library. Hope this document could help you:
The runtime libraries and apps compiled by any of these versions of the compiler are binary-compatible. It's reflected in the C++ toolset major number, which is 14 for all three versions. (The toolset version is v140 for Visual Studio 2015, v141 for 2017, and v142 for 2019). Say you have third-party libraries built by Visual Studio 2015. You can still use them in an application built by Visual Studio 2017 or 2019. There's no need to recompile with a matching toolset. The latest version of the Microsoft Visual C++ Redistributable package (the Redistributable) works for all of them.
I reinstalled Visual Studio 2017 and just couldn't configure a working Kit for Qt.
Summary:
At the very beginning, I had both Qt5.9.8 MSVC2017_64bit and Visual Studio 2017 installed on my computer. They just worked fine. Then I updated Visual Studio to 2019 and uninstalled VS2017. Then my Qt Creator broke down. When I try to open a Qt project created before, it just prompts me that "No valid kits found".
What I tried :
I tried to reinstall something 'needed', attempting to restore something for Qt to work. So I opened Visual Studio Installer, checked to install Single Component "VC++ 2017 version 15.9 v14.16 latest v141 tools" of Visual Studio Enterprise 2017. Then I opened Qt Creator 4.8.2, Menu->Tools->Kits, manually added a clang-cl C and C++ compiler and set the compiler path each to "C:\Program Files (x86)\Microsoft Visual Studio\2017\VC\Tools\MSVC\14.16.27023\bin\Hostx64\x64\cl.exe".
I also tried some combinations between Hostx64, Hostx86 and x64, x86 when selecting the path. But none of then succeeded.
Besides, I have heard and taken a shot on Qt VS Tools.
Related environments:
Microsoft Visual Studio 2019 Enterprise
Microsoft Visual Studio 2008 Professional (whose compiler was
auto-detected in Qt but not usable)
Qt 5.9.8 MSVC2017_64bit
Question :
Would anyone tell me what I can do to solve this troubling problem?
cl.exe is not clang, so you will not make it work by forcing cl.exe into a clng configuration in Qt Creator.
As of today, there is no way to set an MSVC compiler toolchain manually in Qt Creator. The only way is to have it auto-detected. If your MSVC toolchain is not detected, the first thing to do is to update Qt Creator (current version is 4.9.2) becaue each released of Qt Creator has improved detection methods for the new MSVC releases.
I know that Microsoft has standardized the way to detect installed toolchains with 2019. So if you use MSVC 2019 + Qt Creator 4.9+, yous should not have any problem.
Note that in the past Qt Creator had issues with:
MSVC Build Tools (MSVC toolchain without Visual Studio GUI)
Installing old toolchains with new installer e.g. installing MSVC 2015 as part of Vistual Studio 2017 installation.
Also, by default Visual Studio does not install the command line debuger by default. You need to go to "Add and remove programs" and modify the Windows SDK installation by enabling the debug tools.
At the official Qt library site present only Qt add-in for Microsoft Visual Studio 2013 and 2015. And there are no one for MSVS 2017.
How to use Qt library with visual studio 2017 in this case?
You can get the add-in beta here, it should be mostly working. I mean if you want IDE integration. Otherwise it should build fine via the build tools command prompt (or however they call it now) via qmake project and then make.
As for building the Qt framework itself, it should probably work too, maybe with the exception of the QWebEngine stuff. It also seems that MSVC 2017 and 2015 are binary compatible, so it may be possible to use Qt binaries, built with MSVC 2015, therefore making it an option to avoid building Qt from source.
IIRC the incoming version 5.9 will offer MSVC 2017 prebuilt binaries.
It looks like using Visual Studio 2010 it is possible to build against the 2008 runtime, if you have both editions installed: Can I use Visual Studio 2010's C++ compiler with Visual Studio 2008's C++ Runtime Library?
Is it possible to do this using just the free Windows Platform SDKs and VS 2010? Just to stress - installing Visual Studio 2008 is not an option.
Background: I'd like to build a Python module for Python 2.7. I have a copy of Visual Studio 2010, but Python 2.7 (specifically the Python(x,y) distribution) is built using 2008. Rebuilding Python, or rebuilding Python(x,y) is not something I want to get into (there are various other modules I want to use as well). My module needs to link against vendor-supplied libraries built using VS 2008/2010 (I've been given both sets of libraries). I don't own a copy of Visual Studio 2008, and I really don't want to have to buy one.
This MSDN article says that although you can change the platform toolset in the IDE you still need to have the VS2008 binaries installed.
I know you said installing 2008 was not an option but perhaps you can still find the free versions in an old SDK or even the Express version on the Microsoft website.