Cannot Run Compiler 'cl'
I've recently updated my Qt to include version 5.9.1 as well as update Qt Creator to 4.3.1. I've previously had Qt 5.7.0 installed and working a treat, using the MSVC 2015 x86 and x64 compilers.
Now, when I try to build a project within Qt Creator, it fails almost immediately with the following error:
Cannot run compiler 'cl'. Maybe you forgot to setup the environment?
If I bring up the
Developer Command Prompt for VS2015, I can see that
clis clearly recognized as a tool.
When I check the Qt Kits, all kits have a yellow exclamation mark next to them reporting the following warnings:
CMake configuration has no path to a C compiler set, even though the kit has a valid toolchain
CMake configuration has no path to a C++ compiler set, even though the kit has a valid toolchain
All 32bit kits have the
Microsoft Visual C++ Compiler 14.0 (x86)C/C++ compilers set and the 64bit ones have the
Microsoft Visual C++ Compiler 14.0 (x86_amd64)C/C++ compilers set.
I'm not really sure what has happened as it was working great with Qt 5.7.0 prior to the updates.
Might be a silly question but are you sure you installed the VS2015 package of Qt 5.9.1 ?
Hi, I've already had the same thought.
But yes, the VS2015 package has been installed - for all versions of Qt on my machine.
Then you should go in the Build and Run panel in the preferences and check if everything is ok with your Kits.
I've already done that - see my first post, the kits are coming up with those warnings.
When I switch to the CMake tab, there are no
cmakesdetected - but there were none previously prior to my Qt update.
cmake is innocent.
Can you show a picture of your Kits, Qt versions and compiler panels ?
As requested, here are links to screen captures taken from Qt Creator:
Qt Build & Run - https://drive.google.com/open?id=0Bw0lw24F4HvoZ3pBWjZ1RUROUmM
Ignore the 5.9.1 MSVC2013 kit - I haven't got the correct Visual Studio compiler installed for that one.
Another strange thing is that you have the x64 debugger selected for your 32bit Qt build.
Good point although I'd be happy if I could get to the debugging phase. As soon as I click build (qmake runs fine), the error appears and I can do nothing else.
Maybe I'll reinstall Visual Studio...
I've already tried reinstalling Qt but this made no difference.
Still the same error ?
Yep, exactly the same error... bizarre
Ok, so something I've just discovered.
Under the Options -> Qbs ->Profiles, when I select the 5.9.1 MSVC2015 32-bit kit and I examine the
compilerNameis empty as is the
toolchainInstallPath. Incidentally, on another machine which works these values are set to
VC/Binpath of the Visual Studio directory.
The question is, how would one change these values?
Meh, it makes no difference - managed to change the values to reflect that of my working system but it still doesn't work. I also installed
cmaketo reduce the number of differences but again, doesn't fix the issue.
Just realised something, you have a QBS project failing ?
If so, does a classic qmake project work ?
It is a Qt Widgets application that is failing - I'm not certain what a Qbs project is. I was purely looking for differences between a known working Qt setup and my current setup.
It's a project using the QBS project manager rather than qmake.
I don't have an exact solution for you, but maybe some helpful information:
I just encountered a very similar problem - we have a command line build and somewhat-complex make system here which calls qmake, etc. via a command line. This make system was built around Qt 5.5.1, and uses the "win32-msvc2015" make spec (e.g. qmake -spec win32-msvc2015). I attempted to use the latest Qt 5.9.1, and our make system failed because the Qt "mkspecs" folder in Qt 5.9.1 now contains a single "win32-msvc" folder, instead of separate "win32-msvc2005", "win32-msvc2008", "win32-msvc2010", "win32-msvc2012", "win32-msvc2013", and "win32-msvc2015" folders as it did in Qt 5.5.1.
I attempted to do some copying/pasting/renaming of folders in order to get our existing make system to build with Qt 5.9.1 (without editing our make system, for reasons I won't get into), but was not successful - the build got farther, past the "Could not find qmake configuration file win32-msvc2015" error I had been seeing, but hit an error similar to what you are seeing: "Project ERROR: Cannot run compiler 'cl'. Maybe you forgot to setup the environment?".
In the end, it was not important for me to use the absolute latest version (Qt 5.9.1), and instead I worked around the problem by just using Qt 5.6.2 instead, which has a folder structure similar to Qt 5.5.1 (what our make system was built around).
My guess is that there was some restructuring done around the MSVC make specs in recent Qt versions, and maybe in other MSVC-build-related areas, which is somehow related to your issue.
(Just some information...)
@Brian-Dolan Thanks for your reply and thanks for the extra information. It got to the point where I uninstalled Qt AND Visual Studio then re-installed both just to see what would happen. When I re-installed Qt Creator, the same problems arose.
It almost had me beat but after a little bit more digging, I've finally managed to sort it.
When I executed the
vcvarsall.batfile from within the Visual Studio / VC directory, I noticed that a couple of issues were being reported in the command line - notably that
MySQL command not foundwhich I thought rather odd - what would MySQL have to do with a Visual Studio install?
Anyhoo, having then removed anything and everything MySQL-related from my system, running the
vcvarsall.batagain yielded no reported issues. I then ran Qt Creator again using a simple example application and now everything works perfectly. All I can think of is that when the
vcvarsall.batreturns an exit code, it was not the exit code expected by Qt Creator due to the MySQL issues. Either that or there was a lingering bath path around used by MySQL which no longer existed and was throwing the toolchain.
Either way, I'm back in business! Thanks for all the comments and help with this.
Well that was a tricky one...
Thanks for sharing your findings !
Since you have it working now, please mark the thread as solved using the "Topic Tools" button so that other forum users may know a solution has been found :)
For me, I had to install Visual C++ 2015 Build Tools for resolving the error (http://landinghub.visualstudio.com/visual-cpp-build-tools).
Batch file C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat didn't found C:\Program Files (x86)\Microsoft Visual C++ Build Tools folder.
Thanks for your post! MySQL was also the culprit on my Qt build. I also installed all MySQL software and then I could build the Qt application without problems!
In my case it was more complex. The antivirus client was tripping up over all the reg query calls in some of the bat files and delaying things sufficiently such that Qt got an incomplete environment. Seems Qt times out when calling vcvarsall. The delays were substantial. Minutes. Observed Qt creating temp bat files to call vcvarsall.bat over and over and over again. The solution I arrived at is to cache the resulting environment in another .bat file that simply sets the environment variables with the determined values. This is updated 1x day and the result is that I can open in Qt and have a working environment. It simply sets the saved environment and skips all the reg query calls. Note that vcvars64 or vcvars32 both make a reg query call for VS140COMNTOOLS. This seems enough of a delay to result in an incomplete path and hence cl.exe missing. I setup the caching within the vcvars64/32 files. If the cache file exists for the day then it's simply loaded, otherwise the reg query process is done to populate the values in case the environment changes and then those variables are written to the cache cmd file.
The other bit of fun is that the order of reg query calls isn't optimized for current systems, meaning it tries several failing paths first, also adding to delay. And most every line in called bat files is prepended with @ (echo off) making debugging harder. That and the subroutines called have > null 2>&1 which also turns off output. So if you need to debug you need to deal with all that. Noticed 2017 bats have two branches of code to allow for debugging.