Some status updates:
I've got the qtwebkit to build ok, using these options:
perl Tools\Scripts\build-webkit \
--qt \
--release \
--cmakeargs="-Wno-dev -DCMAKE_PREFIX_PATH=path_to_qt5_static_install_dir -G\"MinGW Makefiles\" -DENABLE_API_TESTS=OFF -DENABLE_TEST_SUPPORT=OFF" \
--makeargs="-j8" \
--install \
--prefix=path_to_qt5_static_install_dir
(note the ENABLE_API_TESTS=OFF and ENABLE_TEST_SUPPORT=OFF defines (which seem to be effective in turning off some internal unit testing apps), plus the "--install" option.
The most important static .a libs that got built are: libJavaScriptCore, libWebCore, libWTF, libwoff2, libbrotli, libQt5WebKit and libQt5WebKitWidgets.
The install part of the build also seemed to follow the standard Qt "protocol" i.e. header, libs and .pri files landing in the right place.
The not-so-great news are:
The QtTestBrowser.exe app shows a message box like "Application failed to start because platform plugin “windows” is missing in path ''", even after copying sibling with it a "platform" dir with qt5 dll plugins etc. And then terminates. Considering the issues depicted in the points below, it is understandable why.
The mingw64 7.3.0 toolchain or qtwebkit build / cmake scripts themselves are doing something odd at linker time: what I have discovered was that the .a static files seemed to be "shallow", in the sense that instead of containing the actual .o / .obj object files, they contained only path strings / references to the actual .o files! Somehow the qt or qtwebkit cmake stuff, or the binutils (ar) part of the toolchain are performing in a very bizarre way. I have to re-assemble all the object files myself with the ar utility (3,000+ files) to finally see the static libs usable in my little test app.
My test app compiles ok, but fails to link - missing symbols are being reported in basic system libs brought by the toolchain itself (i.e. libws2_32.a, libshell32.a, libicu*.a, libxml2.a, libxslt.a, etc). Which is very strange because the libs are really there and are truly static i.e. I do see the allegedly missing symbols there. Because I saw __imp_xyz prefixes reported in those missing names.
I suspect that some mix-up occurs between static and import libs - very probably due to some of the libs brought by the qtwebkit itself inside "<qtwebkit_src_dir>\WebKitLibraries\win". Although those end up in .lib and not having the "lib" prefix in their name, so very probably they are msvc-based. And the qtwebkit's configure reported the dependent libs as coming from somewhere else i.e. the toolchain.
Very strange.
Today I'll redo all these steps with msvc - even if it fails at least it may give me more insights as to what happens under the hood with qtwebkit build script. And even if that doesn't work, it helps clear my mind a little and make me ready to tackle using an older gcc toolchain or do other patching in qt5 itself.
Thank you.