5.12 new install, not finding Windows SDK
-
My system:
Win7 Pro 64-bit
MSVC 2017 32-bit
Windows Kit 10 (various versions installed)
Qt 5.12.0 clean install, selected MSVC 2017 32-bit compilerMSVC works fine on projects unrelated to Qt. My Qt project builds and runs fine on a 32-bit Windows machine with the same compiler. I installed 5.12.0 on this 64-bit machine, copied my project source directory from the other machine, and tried to build it, but it's not finding the Windows Kit that contains the standard headers and libraries.
When I look at the Makefile (actually the .qmake.stash file) generated on the two systems, the one from the working system contains six Windows Kit directories in the QMAKE_CXX.INCDIRS variable, plus three in QMAKE_CXX.LIBDIRS, while the one from the non-working system doesn't have these. If I delete the build directory, I get the same error again.
I looked in Tools->Options->Kits->Compilers, and the working machine lists the Windows SDK, while the non-working machine doesn't. There are other differences, appearing that the "clean" installation found some artifacts of an older 5.11 installation which I had "completely" removed before installing 5.12.
So how do I fix this? Is there a way to provoke another auto-detect? Is there some bug that makes it fail to auto-detect the Windows Kit in "Program Files (x86)" when running on a 64-bit machine, even though it has no trouble finding the 32-bit compiler itself?
Update:
Here's another strange thing. On the working machine, Tools->Options->Kits->Debuggers found CDB in C:\Program Files\Debugging Tools for Windows (x86). On the non-working machine, which supposedly can't find the Windows Kit, it found CDB in C:\Program Files (x86)\Windows Kits\10\Debuggers\x86 and also in ...\x64. The same information appears in Kits->Kits under Debugger. Everything else in the Kits section matches.
-
My system:
Win7 Pro 64-bit
MSVC 2017 32-bit
Windows Kit 10 (various versions installed)
Qt 5.12.0 clean install, selected MSVC 2017 32-bit compilerMSVC works fine on projects unrelated to Qt. My Qt project builds and runs fine on a 32-bit Windows machine with the same compiler. I installed 5.12.0 on this 64-bit machine, copied my project source directory from the other machine, and tried to build it, but it's not finding the Windows Kit that contains the standard headers and libraries.
When I look at the Makefile (actually the .qmake.stash file) generated on the two systems, the one from the working system contains six Windows Kit directories in the QMAKE_CXX.INCDIRS variable, plus three in QMAKE_CXX.LIBDIRS, while the one from the non-working system doesn't have these. If I delete the build directory, I get the same error again.
I looked in Tools->Options->Kits->Compilers, and the working machine lists the Windows SDK, while the non-working machine doesn't. There are other differences, appearing that the "clean" installation found some artifacts of an older 5.11 installation which I had "completely" removed before installing 5.12.
So how do I fix this? Is there a way to provoke another auto-detect? Is there some bug that makes it fail to auto-detect the Windows Kit in "Program Files (x86)" when running on a 64-bit machine, even though it has no trouble finding the 32-bit compiler itself?
Update:
Here's another strange thing. On the working machine, Tools->Options->Kits->Debuggers found CDB in C:\Program Files\Debugging Tools for Windows (x86). On the non-working machine, which supposedly can't find the Windows Kit, it found CDB in C:\Program Files (x86)\Windows Kits\10\Debuggers\x86 and also in ...\x64. The same information appears in Kits->Kits under Debugger. Everything else in the Kits section matches.
You could create your kit manually, which is what I usually do instead of relying on the autodetection. Add the compilers if missing, then add the debuggers if missing, add Qt version if missing. Then add a kit and select a compiler and debugger and Qt version from the predefined ones.
-
You could create your kit manually, which is what I usually do instead of relying on the autodetection. Add the compilers if missing, then add the debuggers if missing, add Qt version if missing. Then add a kit and select a compiler and debugger and Qt version from the predefined ones.
@kshegunov I could, except that I have no idea how to configure it. What's missing is the Windows SDK, not the compiler or debugger. If I go into Tools->Options->Kits->Compilers, I see an Add button with various choices, with Custom->C or Custom->C++ looking like the only vaguely relevant choice, but what am I supposed to type in?
On the working machine, I went to Tools->Options->Kits->Compilers, and tried selecting the SDK and clicking Clone, and guess what, there's a bug: instead of cloning it into the Manual C++ branch at the bottom, where I could open it up and see what settings are contained in it, and copy them into the other machine, it just makes a useless copy of it in the same Auto-detected C++ branch where it is already located, and where it can't be edited. So I have no way of seeing what's in it. Is it actually contained in a file somewhere that is human-readable without being some kind of wizard?
-
@kshegunov I could, except that I have no idea how to configure it. What's missing is the Windows SDK, not the compiler or debugger. If I go into Tools->Options->Kits->Compilers, I see an Add button with various choices, with Custom->C or Custom->C++ looking like the only vaguely relevant choice, but what am I supposed to type in?
On the working machine, I went to Tools->Options->Kits->Compilers, and tried selecting the SDK and clicking Clone, and guess what, there's a bug: instead of cloning it into the Manual C++ branch at the bottom, where I could open it up and see what settings are contained in it, and copy them into the other machine, it just makes a useless copy of it in the same Auto-detected C++ branch where it is already located, and where it can't be edited. So I have no way of seeing what's in it. Is it actually contained in a file somewhere that is human-readable without being some kind of wizard?
I meant a very specific set of steps:
- Point Creator to the compiler
- Point Creator to the debugger
- Point Creator to a Qt version
- And finally create a kit from the above three
... - Hack away with your new kit by configuring your project to use it.
Here's also step-by-step by Chris: https://forum.qt.io/topic/78962/how-to-use-qt-with-visual-studio-2017/13
(I imagine it could be useful as I stick tomingwand am not "fully versed" in all things microsoft) -
I meant a very specific set of steps:
- Point Creator to the compiler
- Point Creator to the debugger
- Point Creator to a Qt version
- And finally create a kit from the above three
... - Hack away with your new kit by configuring your project to use it.
Here's also step-by-step by Chris: https://forum.qt.io/topic/78962/how-to-use-qt-with-visual-studio-2017/13
(I imagine it could be useful as I stick tomingwand am not "fully versed" in all things microsoft)@kshegunov Unfortunately, those instructions are for creating a kit where one doesn't exist, and don't say anything about adding the Windows SDK. However, I see that the bug that prevents me from cloning my working kit to see what's in it has been fixed, so I may just wait until 5.12.1 is released, and see if I can learn what I need to add to my non-working kit.
-
@kshegunov Unfortunately, those instructions are for creating a kit where one doesn't exist, and don't say anything about adding the Windows SDK. However, I see that the bug that prevents me from cloning my working kit to see what's in it has been fixed, so I may just wait until 5.12.1 is released, and see if I can learn what I need to add to my non-working kit.
-
@pderocco
this sometimes happens when you update QtC or the Qt version. For what ever reason.A complete reinstall usually fixes that, alternatively, you can add the kit path manually to the project settings path like I did for 5.11.3
@J.Hilk A complete reinstall did bupkis.
I have no idea how to set this up. When I look at my working 32-bit system, under Tools->Options->Kits->Compilers->Auto-detected->C++, I see three Windows SDKs mentioned, the relevant one being
Microsoft Windows SDK for Windows 7 (7.0.7600.16385.40715) (x86)
When I click on it, it shows:
Initialization: C:\Program Files\Microsoft SDKs\Windows\v7.0\bin\SetEnv.cmd /x86
This is a nearly 700-line batch file that looks like the Windows equivalent of a configure script. If I try running it manually in a cmd window, I get errors, so I can't really figure out what it is adding to the environment when it is run by Qt Creator.
When I go to the non-working 64-bit system, under Tools->Options->its->Compilers, I don't see the SDKs, and the Add button on the right gives me the following hierarchy of choices:
Add clang-cl C C++ MinGW C C++ GCC C C++ Clang C C++ Custom C C++ QCCNothing about Microsoft, so I clicked Custom C++ and got
I get a fancy dialog with entries for- Name
- Compiler path
- Make path
- ABI
- Predefined macros
- Header paths
- C++11 flags
- Qt mkspecs
- Error parser
Nothing about specifying an initialization command, which would mimic what gets auto-detected on the working 32-bit system.
When I look at your screen cap, it looks like you were fiddling with the PATH variable. I don't know what this would have to do with finding header files, since the PATH is for executables.
The long and the short of it is that I don't see any way to get this working. Even if I beat my head against the wall for a day and get something that sort of seems to work, I don't know if I'll discover something is missing that I didn't know I needed. This is just broken, and it shouldn't be my job to fix Qt's bug.
-
I managed to get this working by reinstalling Qt from scratch, and this time specifying 64-bit MSVC as the compiler, instead of 32-bit. There really isn't a 64-bit version of the compiler--there's only one installation package for Visual Studio, and it winds up in C:\Program Files (x86) on a 64-bit system, but it includes 32-bit and 64-bit debuggers. I had chosen 32-bit when originally installing Qt, because I wanted to make sure I'd get the same 32-bit executables regardless of which machine I built on.
So I can now build on the 64-bit machine, but I'm getting a 64-bit program, which isn't what I want. This isn't an enormous program that needs more than 4GB of address space, and I'd like to be able to deploy it on 32-bit machines. I guess my only solution is to settle for 64-bit builds while I'm debugging on my 64-bit machine, and then rebuild a 32-bit version on my 32-bit machine when it's time to deploy. That's irritating, but I'm going to have to build a Mac version on my Mac, and a Linux version on my Linux machine, too, so it's just more of the same.
-
I managed to get this working by reinstalling Qt from scratch, and this time specifying 64-bit MSVC as the compiler, instead of 32-bit. There really isn't a 64-bit version of the compiler--there's only one installation package for Visual Studio, and it winds up in C:\Program Files (x86) on a 64-bit system, but it includes 32-bit and 64-bit debuggers. I had chosen 32-bit when originally installing Qt, because I wanted to make sure I'd get the same 32-bit executables regardless of which machine I built on.
So I can now build on the 64-bit machine, but I'm getting a 64-bit program, which isn't what I want. This isn't an enormous program that needs more than 4GB of address space, and I'd like to be able to deploy it on 32-bit machines. I guess my only solution is to settle for 64-bit builds while I'm debugging on my 64-bit machine, and then rebuild a 32-bit version on my 32-bit machine when it's time to deploy. That's irritating, but I'm going to have to build a Mac version on my Mac, and a Linux version on my Linux machine, too, so it's just more of the same.
