Details
-
Bug
-
Resolution: Done
-
Not Evaluated
-
1.14.0
-
None
-
Windows
-
2f34e637828f7e519a25a498bd5aa4e8f955217d (qbs/qbs/1.19)
Description
We have installed Visual Studio build tools 2019 in a Windows docker container. This is the components that we install:
RUN Start-Process -FilePath .\vs_buildtools_2019\vs_buildtools__253442717.1528806559.exe -NoNewWindow -Wait -ArgumentList \ '--quiet', \ '--wait', \ '--norestart', \ '--nocache', \ '--installPath C:\BuildTools', \ '--add Microsoft.VisualStudio.Workload.VCTools', \ '--add Microsoft.VisualStudio.Component.WinXP', \ '--add Microsoft.VisualStudio.Workload.ManagedDesktopBuildTools', \ '--add Microsoft.VisualStudio.Component.VC.140', \ '--add Microsoft.VisualStudio.Component.VC.v141.x86.x64', \ '--add Microsoft.VisualStudio.Component.VC.CMake.Project', \ '--add Microsoft.VisualStudio.Component.VC.Tools.x86.x64', \ '--add Microsoft.Component.MSBuild', \ '--add Microsoft.VisualStudio.Component.Windows10SDK.16299', \ '--add Microsoft.VisualStudio.Component.Windows10SDK.17134', \ '--add Microsoft.VisualStudio.Component.Windows10SDK.18362', \ '--add Microsoft.Net.ComponentGroup.TargetingPacks.Common', \ '--add Microsoft.VisualStudio.Workload.NetCoreBuildTools', \ '--add Microsoft.Net.Component.4.7.SDK', \ '--add Microsoft.Net.Component.4.7.TargetingPack', \ '--add Microsoft.Net.ComponentGroup.4.7.DeveloperTools', \ '--add Microsoft.VisualStudio.Component.TestTools.BuildTools', \ '--add Microsoft.VisualStudio.Wcf.BuildTools.ComponentGroup'; \
If we check the installed versions with vswhere.exe, it only shows VisualStudio.14.0 installed, which I think is one of the 2015 versions:
& '.\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe' -all -legacy
Visual Studio Locator version 2.6.7+91f4c1d09e [query version 2.1.1046.44959]
Copyright (C) Microsoft Corporation. All rights reserved.instanceId: VisualStudio.14.0
installationPath: C:\Program Files (x86)\Microsoft Visual Studio 14.0\
installationVersion: 14.0
This might have something to do with build tools not being the normal Visual Studio.
The qbs toolchain is set up like this:
RUN qbs setup-toolchains --system --type msvc "C:\BuildTools\VC\Tools\MSVC\14.16.27023\bin\HostX64"\x86\cl.exe" msvc_x86; \ qbs setup-qt --system "C:\Qt\5.12.5\msvc2017\bin\qmake.exe" msvc_x86_qt ; \ qbs config profiles.msvc_x86_qt.baseProfile msvc_x86
Qbs then uses the path to cl.exe to find the correct vcvarsall.bat to call. From what I understand, there are functions in vsenvironmentdetector.cpp in Qbs, that calls vcvarsall.bat something like this:
call "C:\BuildTools\VC\Auxiliary\Build\vcvarsall.bat" x86
This call to vcvarsall.bat sets up the correct environment variables for x64 host and x86 target, but it uses the latest installed toolset. From the help of vcxvarsall.bat:
PS C:\BuildTools\vc\Auxiliary\Build> .\vcvarsall.bat
[ERROR:vcvarsall.bat] Error in script usage. The correct usage is:
Syntax:
vcvarsall.bat [arch] [platform_type] [winsdk_version] [-vcvars_ver=vc_version] [-vcvars_spectre_libs=spectre_mode]
...
[vc_version] : {none} for latest installed VC++ compiler toolset
The end result when compiling my test project is this:
... C:\BuildTools\VC\Tools\MSVC\14.22.27905\include\yvals_core.h(337): fatal error C1189: #error: STL1001: Unexpected compiler version, expected MSVC 19.22 or newer.
You can see that Qbs uses include files in 14.22.27905, but I have set up the toolchain to use cl.exe from 14.16.27023.
------
Is there a way of telling Qbs which version of the toolchain to use?
I tried hacking around it by renaming the real vcvarsall.bat and replacing it with this:
call %~dp0vcvarsall_real.bat x86 store 10.0.16299.0 -vcvars_ver="14.16.27023"
I then no longer get the error about the wrong compiler version. Instead I get other errors, like this:
C:\Qt\5.12.5\msvc2017\include\QtCore/qglobal.h(45): fatal error C1083: Cannot open include file: 'type_traits': No such file or directory
It looks like there's a wrong or missing include directory, but that might happen when trying to hack around things 
Update of workaround
A proper workaround looks like this:
call %~dp0vcvarsall_real.bat x86 10.0.16299.0 -vcvars_ver=14.16.27023
There shouldn't be any quotes around the vcvars_ver number, and you shouldn't write anything at all for the platform if you want to compile a normal windows application. If you use "store", then you compile in some other way so that your binaries will depend on MSVCP140_APP.dll.