Cannot build Qt 5.7.1 with VS 2015 x64 (WebEngine fails)

flint

I'm trying to build Qt 5.7.1 x64 using Visual Studio 2015 Update 3 CE. Here is how I create my environment:

@echo off

SET QTVER=5.7.1
CALL "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64
SET CDB_PATH=c:\Program Files (x86)\Windows Kits\10\Debuggers
SET QTDIR=C:\Programs\Qt\%QTVER%-x64
SET PATH=%QTDIR%\bin;C:\Programs\Qt\qt-creator\bin;C:\Programs\OpenSSL\x64\bin;%PATH%
SET QMAKESPEC=win32-msvc2015
SET INCLUDE=C:\Programs\OpenSSL\x64\include;%INCLUDE%
SET LIB=C:\Programs\OpenSSL\x64\lib;%LIB%
SET LIBPATH=C:\Programs\OpenSSL\x64\lib;%LIBPATH%
SET _ROOT=C:\Programs\Qt\%QTVER%-src
SET PATH=%_ROOT%\qtbase\bin;%_ROOT%\gnuwin32\bin;%PATH%

SET INCLUDE=%INCLUDE%;C:\Program Files (x86)\Windows Kits\10\Include\10.0.10240.0\ucrt
SET LIB=%LIB%;C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64
SET LIBPATH=%LIBPATH%;C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\ucrt\x64
SET PATH=%PATH%;C:\Program Files (x86)\Windows Kits\10\bin\x64\ucrt

My Qt configuration:

C:\Programs\Qt\5.7.1-src\configure.bat -prefix C:\Programs\Qt\5.7.1-x64 -mp -opensource -confirm-license -nomake tests -nomake examples -no-compile-examples -release -debug-and-release -qt-zlib -qt-pcre -no-icu -qt-libpng -qt-libjpeg -qt-doubleconversion -qt-freetype -ssl -openssl

First, when build comes to WebEngine it fails on qtwebengine\src\3rdparty\chromium\device\bluetooth\bluetooth_init_win.cc file because the function __HrLoadAllImportsForDll() is not declared anywhere in Qt or SDK. Well, this one I could work around by replacing the whole HasBluetoothStack() body with return false; (someone in the Internet suggested that) but I still wonder how is that supposed to compile? Do I need some special SDK for that?

After that the build went on, but then failed with another kind of error:

c:\program files (x86)\windows kits\10\include\10.0.10240.0\um\wrl\event.h(458): error C3646: '_agileptr': unknown override specifier

As far as I understood, it cannot find the AgileRef type used in that event.h in the line 458:

AgileRef _agileptr;

I can see that binary installation of Qt for VS2015 does include QtWebEngine module, so there must be a way to build it, but how? What could be the source of the problem?

m.sue

Hi,
your WINDOWS SDKs seem to have another structure than mine:

the directory "10.0.10240.0\um\wrl" does not exist in my SDK. My system finds "event.h" in "10.0.14393.0\winrt\wrl".
my system finds AgileRef in "10.0.14393.0\winrt\wrl\client.h".

-Michael.

flint

@m.sue
Looks like I've found what the problem is. Indeed, the SDK is missing required headers, and this is very interesting because Microsoft claims that SDK 10 is included into VS2015u3. Looks like I still have to download a standalone SDK 10 and install it on top, but when I tried to do it I've got a failure with a very vague error message hidden inside a huge log file. Luckily, in the Internet I found an explanation of it, which is that SDK 10 requires Windows 8 x64 or higher to install because it needs Hyper-V, and I have Windows 7. (I wonder how the heck a usual general-purpose SDK ended up with such a requirement!)

So, yeah, the summary: you've got VS2015 which officially supports Win7, and which is claimed to have SDK 10 already, and that build-in SDK is wrong, and when you try to get the real SDK 10 it's Win8+ only. And more, when you try to install that SDK on an unsupported OS it does not tell you about that straight away, it just spends a lot of time trying to install, then rolling back and leaves you with the "failed" status and many-megabyte logs to sieve through. Excellent and comprehensive design, that is.

Anyway, after I discovered all this, I noticed there are some older versions of SDK 10 available for download. So I tried SDK 10586, and it installed without any trouble. So I reconfigured my paths to use 10.0.10586.0 instead of 10.0.10240.0 and tried rebuilding Qt, and this time it went completely OK. However, I forgot to revert my change about that Bluetooth function, so I'm not sure that got fixed (it's the next thing I'm going to check), but still it's nice progress.

Added:
Unfortunately, no, that __HrLoadAllImportsForDll is still not accessible, so the first mistery remains unsolved. I found declaration in the file c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\delayimp.h, but it's missing in the SDK's delayimp.h (which is probably used instead), so I copied its declaration into the file, and build went OK. I wonder how it's supposed to work without such manual intervening.

ambershark

Added:
Unfortunately, no, that __HrLoadAllImportsForDll is still not accessible, so the first mistery remains unsolved. I found declaration in the file c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\delayimp.h, but it's missing in the SDK's delayimp.h (which is probably used instead), so I copied its declaration into the file, and build went OK. I wonder how it's supposed to work without such manual intervening.

Wait are you mixing and matching headers from different SDKs? That is definitely not a good idea. Almost guaranteed to break pretty much everything you try to do.

The likely reason for that not existing is because you are building for Win CE. CE supports only a small subset of the winapi. I don't know for a fact as I'm not much for Windows CE, it's end of life is coming up soon, and it hasn't been actively developed in quite a few years. I'm just guessing here but in my very limited CE work this was always the case with "missing" functions.

flint

@ambershark

Wait are you mixing and matching headers from different SDKs? That is definitely not a good idea. Almost guaranteed to break pretty much everything you try to do.

I would definitely like to avoid that, and with earlier VS and SDK versions I never had to, but now if I just run the vcvarsall.bat and try to build something, the compiler simply cannot find and include some header files which are ONLY present in the versioned SDK folders. I googled much about it, and they say it's Microsoft's bug, and we have to manually add the versioned header/lib directories until they fix this in Visual Studio scripts. So I did that (the last 4 lines in my script, that's why they are separated from the previous ones).

Do you maybe have better suggestions on how to create a working build environment?

The likely reason for that not existing is because you are building for Win CE.

No, I'm not. I posted my script for creating build environment, you can see that I use "amd64" buld target when calling vcvarsall.bat.

m.sue

Hi,
The delayimp.h is part of the Windows SDK v6.0, which is quite old and nobody expects that you have it around anymore, I assume. In my Win10 installation the file is no longer in any current SDK, but - as you found out yourself - part of the VS 2015 (Update 3) includes, so (luckily(?)) I have no contradicting versions.

I did have no problem to install the 10.0.10586.0 SDK on Win7 (on some older machine) at 2016-2-22. So I assume that it was possible if done via the VS 2015 (Update 1) setup program, when it was current.
-Michael.

ambershark

@flint said in Cannot build Qt 5.7.1 with VS 2015 x64 (WebEngine fails):

@ambershark

Wait are you mixing and matching headers from different SDKs? That is definitely not a good idea. Almost guaranteed to break pretty much everything you try to do.

I would definitely like to avoid that, and with earlier VS and SDK versions I never had to, but now if I just run the vcvarsall.bat and try to build something, the compiler simply cannot find and include some header files which are ONLY present in the versioned SDK folders. I googled much about it, and they say it's Microsoft's bug, and we have to manually add the versioned header/lib directories until they fix this in Visual Studio scripts. So I did that (the last 4 lines in my script, that's why they are separated from the previous ones).

Do you maybe have better suggestions on how to create a working build environment?

The likely reason for that not existing is because you are building for Win CE.

No, I'm not. I posted my script for creating build environment, you can see that I use "amd64" buld target when calling vcvarsall.bat.

@flint Oh sorry I thought you were mixing actual header files. I.e. not just telling the build system where to find the platformsdk headers but actually copying them from 1 directory to another, thus mixing incorrect .h files with corresponding .libs. :)