For the same QtWebkit 5.212 branch, but cloned from http://code.qt.io/cgit/qt/qtwebkit.git/ and building with the MSVC 2017 (x64) toolchain (and against a static qt-5.10.1 build which also used -static-runtime), I am getting an even more serious error:
All the .exe files which the build-webkit perl script had itself produced inside WebKitBuilt\Release\bin64 are simply crashing / segfault-ing right at startup, with a 0xc0000005 access violation.
This includes QtTestBrowser.exe itself. Only the javascript interpreter console utility seems to start and work fine.
The same thing happens with any simple Qt test app that links against "CONFIG += webkitwidgets" and just attempting to instantiate a QWebView (just the constructor, nothing else like load() etc).
Any idea as to why I'm experiencing that?
My build-qtweb script args are "--no-location", "--no-xslt", "--only-webkit" and some explicit include and lib paths specified via the "--cmake-args", for: sqlite, libjpeg, libpng, libxml and an include for ICU.
Oh, and in order for the build to work against libs that were built using "static runtime mode" (/MT flag) - including the qt-5.10.1 itself (which was built with "-static" and "-static-runtime"), I had to manually flip a USE_STATIC_RUNTIME local var in Qt5ConfigOptions.cmake from OFF to ON. Otherwise, the nmake would report thousands of errors like mismatch between "MT_static" and "MD_dynamic" mode - mostly when linking against qt 5 code.
With the same qtwebkit code base but using Alexpux' MSYS2 mingw64 toolchain (based on gcc / g++ 7.3.0), the resulting QtTestBrowser.exe was at least able to start and show some standard info dialog like " "Application failed to start because platform plugin “windows” is missing in path ''".
The positive aspect with the MSVC 2017 toolchain was that my little Qt test app was able to link right-on with the resulting qtwebkit static .lib files (the mingw64 is having some hiccups which I hope to fix in the meantime - very probably caused by some import libs inter-mixed with true static libs in the toolchain's standard prefix dir).
I'll add these status updates for the MSVC 2017 toolchain here:
https://forum.qt.io/topic/88530/linker-error-while-building-qtwebkit-statically-against-working-qt-5-10-1-static-build-on-windows/3
Would you think that my segfault is caused by "static vc/windows runtime" mode (/MT) enabled in almost all third-party open-source libs (icu, libz, libpng, libxml, sqlite, libjpeg)? Haven't touched openssl (which is 1.0.2n and qt 5.10.1 is instructed to statically link against it). The build-webkit perl script and nmake building went very smoothly - barely saw some warnings like /nodefaultlib:msvcrt or microsoft linker switching to a different mode due to seeing /LRTG or something.
Or is my crash happening due to those opensrc libs not being built ok? But how come qt5 itself - which is instructed to use ssl and icu (but not the rest), can work just fine?
Or maybe the QtTestBrowser.exe or any qt test app that wants to use webkitwidgets needs some other config files or env vars present (fonts??)
Or maybe the CMAKE_PREFIX_PATH define that I am putting in --cmakeargs (path_to_qt5_static_install_BASE_dir not the inner qtbase/ subdir) is wrong? But the QtTestBrowser.exe is considered autonomous, right? Like at that point in time when it gets built, no dependency on qt5 source tree or libs is required, right? Because the qt5 is the one receiving new libs, headers, .pri and .pc files once the qtwbekit got built 100% and "make install" was invoked".
Thanks and I hope I haven't hijacked this thread. Somehow I feel we are both onto something here.
