qtwebkit broken after qt5 update (bad icu version)

[omichel]

After recompiling my Qt5 app with qt5-5.13.2-1, I am getting the following error box:

This application failed to start because no Qt platform plugin could be initialized.
Reinstalling the application may fix this problem.
Available platform plugins are: direc2d, minimal, offscreen, webgl, windows.

Other qt applications (such as qtcore and linguist) seems to work fine.

When opening my app in dependency walker, I see that Qt5Core.dll, Qt5Gui.dll, Qt5Widgets.dll and Qt5PrintSupport.dll appear in read (broken).

Also, the version of my app installed outside the MSYS2 environment seems to be broken as well... Similarly the linguist version that is bundled with my app is also broken the same way. That shouldn't happen... I am wondering if Qt is writing something in the Windows registry or global configuration file that I should reset to fix it.

[Alexpux]

@omichel see your installation log maybe qtbinpatcher fail to patch some qt dlls. Then reinstall qt or run qtbinpatcher command manually

[omichel]

I investigated the issue and found that the problem comes from qtwebkit. It should be rebuilt with icu65.x (instead of icu64.x which was removed by qt5 update). If I copy the libicu*64.dll from the previous version into /mingw64/bin, my app works again. This already happened several times, see #5273.

[Alexpux]

@omichel qtwebkit no more buildable so I can’t fix it in near future

[omichel]

OK, hopefully it could be fixed sooner or later... Let me know if I can help.

[janos-varga]

@Alexpux I think I found a fix.
In qtwebkit-5.212.0-alpha2/Source/WebCore/dom/Document.cpp the macro U16_NEXT is used three times (lines 4410, 4415, 4477). Adding a semicolon at the end of these lines fixes the problem and I can build the mingw-w64-qtwebkit package successfully.
See here.
Hope that helps.

[Alexpux]

I already have this patch but it not solve build problems. Builds always crashing with GCC internal error on other file

[janos-varga]

I probably should have shared details of my setup:

• Windows 10 build 1809
• GCC 9.2.0-2
• CMake 3.15.5-1
• Qt 5.13.2-1
• Ruby 2.6.5-2
• Perl 5.30.0-1
• ICU 65.1-1
• Python 2.7.17-1

[Alexpux]

@janos-varga see:

C:/building/msys64/mingw64/include/c++/9.2.0/bits/unique_ptr.h:421:33:   required from 'class std::unique_ptr<unsigned char []>'
E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WebCore/css/CSSParser.h:614:30:   required from here
C:/building/msys64/mingw64/include/c++/9.2.0/bits/unique_ptr.h:120:11: internal compiler error: Aborted
  120 |     class __uniq_ptr_impl
      |           ^~~~~~~~~~~~~~~
In file included from C:/building/msys64/mingw64/include/c++/9.2.0/memory:80,
                 from E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WTF/wtf/StdLibExtras.h:31,
                 from E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WTF/wtf/FastMalloc.h:26,
                 from E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WebCore/config.h:75,
                 from E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WebCore/editing/AlternativeTextController.cpp:27,
                 from E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WebCore/editing/EditingAllInOne.cpp:28:
C:/building/msys64/mingw64/include/c++/9.2.0/bits/unique_ptr.h: In instantiation of 'class std::__uniq_ptr_impl<unsigned char, std::default_delete<unsigned char []> >':
C:/building/msys64/mingw64/include/c++/9.2.0/bits/unique_ptr.h:421:33:   required from 'class std::unique_ptr<unsigned char []>'
E:/mingwbuild/mingw-w64-qtwebkit/src/qtwebkit-5.212.0-alpha2/Source/WebCore/css/CSSParser.h:614:30:   required from here
C:/building/msys64/mingw64/include/c++/9.2.0/bits/unique_ptr.h:120:11: internal compiler error: Aborted
  120 |     class __uniq_ptr_impl
      |           ^~~~~~~~~~~~~~~
make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:12265: Source/WebCore/CMakeFiles/WebCore.dir/inspector/InspectorAllInOne.cpp.obj] Error 1
make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:12174: Source/WebCore/CMakeFiles/WebCore.dir/svg/SVGAllInOne.cpp.obj] Error 1
make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:12213: Source/WebCore/CMakeFiles/WebCore.dir/rendering/RenderingAllInOne.cpp.obj] Error 1
make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:12278: Source/WebCore/CMakeFiles/WebCore.dir/html/HTMLElementsAllInOne.cpp.obj] Error 1
make[2]: *** [Source/WebCore/CMakeFiles/WebCore.dir/build.make:12291: Source/WebCore/CMakeFiles/WebCore.dir/editing/EditingAllInOne.cpp.obj] Error 1

[janos-varga]

That is odd.
I'm afraid I have no idea where this might be coming from :(

[Alexpux]

@janos-varga I think we need wait new release from @annulen based on modern webkit sources as current is too buggy for GCC 9

[annulen]

@Alexpux, given that 5.212 works just fine with GCC 9 on Linux, and modern WebKit is much more intensive in use of modern C++ features, I wouldn't hold my breath

[annulen]

IMO, more perspective options are

• try switching build to using clang-mingw, or
• try to report bug to MinGW developers, or at least produce minimal test case for aforementioned internal compiler error

[Alexpux]

@annulen only debug builds are broken. Release at least builds

[annulen]

This is yet another proof that bug is in the compiler

[mati865]

try to report bug to MinGW developers

It's GCC bug, Windows and Linux don't share 100% of the code and the compiler should never ICE.

[annulen]

Compiler can have legitimate ICE when code violates language rules or invokes undefined behavior which can be proved statically. But this is obviously not the case here.

[revelator]

GCC bug seems indeed possible, i just successfully compiled it with gcc-7.4.0 but gcc-9.2.0 is a nogo.
literally getting hundreds of these errors ->
C:/Msys64/mingw32/include/c++/9.2.0/bits/unique_ptr.h:263:2: error 'value' is not a member of 'std::is_reference<std::default_deletestd::thread::_State >'

[revelator]

64 bit gcc-9.2.0 builds but 32 bit gcc-9.2.0 segfaults as some have pointed out.
some older gcc versions also had this behaviour as far as i could glean from bug reports so it might have been reintroduced with the changes to support c++17. Probably an old hack was needed to get around errors like this on windows builds back then and the dev forgot what it was for in later builds.

[Alexpux]

Resolved by 5a56890

[omichel]

Great! Thank you.