Building using MSys2's MinGW toolchain

[rashil2000]

So I built neovim-qt using two methods -

• one as described in the Wiki, where we download Qt Community installer and select the Qt5 and MinGW options
• the other where I install the required dependencies using pacman in MSys2 - like so pacman -S mingw-w64-x86_64-{libtool,cmake,perl,python2,ninja,diffutils,pkg-config,make,qt5,gcc}.

Both builds were successful. However, there is one problem. The binary created from the second method requires way more number of DLLs in the exe directory. See the screenshot below:

• First method:
  

• Second method:
  

Why is this so? Aren't both methods using the same MinGW toolchain after all?

[jgehrig]

@rashil2000

I'm not sure... The DLL output you see in the first example is typically what I encounter.

The DLLs are included based on the windeployqt, whatever it decides to copy is placed the output directory. That accounts for HOW.

The toolchain you're using is different between the two examples. Both nvim-qt.exe are different. WHY? A few guesses: different GCC versions, different build options were used to generate the GCC binary, different linker, etc.

[jgehrig]

Marking as closed. I don't think there is an issue here.

Feel free to keep commenting.

[rashil2000]

I'm not sure... The DLL output you see in the first example is typically what I encounter.

By which method, first one or second one?

The DLLs are included based on the windeployqt, whatever it decides to copy is placed the output directory. That accounts for HOW.

For both the methods, the contents of windeployqt folder are same, but the second method does not run (the executable, by double-clicking on it) unless I copy all the additional DLLs into the folder too.

...different GCC versions, different build options were used to generate the GCC binary, different linker, etc.

I used the same commands (as mentioned in the Wiki) to build in both the cases. But yes, maybe the compiler/linker versions are different. But surely the difference won't be as much so as to require so many additional DLLs?

[jgehrig]

This looks like a configuration issue with your system.

Building with Windows + MinGW + Qt is non-trivial. Usually Qt has specific compiler version requirements on Windows. Be careful of package version compatibility.

You can see the typical set of DLLs by looking at the pre-compiled binary.

Here are the DLLs included with the latest MinGW build of master:

D3Dcompiler_47.dll
libEGL.dll
libgcc_s_dw2-1.dll
libGLESV2.dll
libstdc++-6.dll
libwinpthread-1.dll
opengl32sw.dll
Qt5Core.dll
Qt5Gui.dll
Qt5Network.dll
Qt5Svg.dll
Qt5Widgets.dll

For both the methods, the contents of windeployqt folder are same, but the second method does not run (the executable, by double-clicking on it) unless I copy all the additional DLLs into the folder too.

I don't follow.

windeployqt is a Qt tool used to analyze the binary and output the necessary DLLs to run it. This tool determines what DLLs are required by analyzing the binary.

But surely the difference won't be as much so as to require so many additional DLLs?

I would not assume this.

You've downloaded two different versions of the compiler, and potentially two different versions of Qt. Both could impact static vs dynamic linkage, libraries consumed, etc.

[rashil2000]

I don't follow.

My bad, I missed mentioning that I copied the additional DLLs from the C:\Msys2\mingw64\bin\. Without these, Windows would give me an error about missing DLLs.

I will try cross checking the compiler/linker versions and installing the specific ones in Msys2.

[rashil2000]

I got the following information:

• Qt Installer:

❯ cmake --version
cmake version 3.19.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).

❯ gcc --version
gcc (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

❯ qtdiag
Qt 5.12.10 (x86_64-little_endian-llp64 shared (dynamic) release build; by GCC 7.3.0) on "windows"

• MSys2:

❯ cmake --version
cmake version 3.20.1

CMake suite maintained and supported by Kitware (kitware.com/cmake).

❯ gcc --version
gcc.exe (Rev11, Built by MSYS2 project) 10.2.0
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

❯ qtdiag
Qt 5.15.2 (x86_64-little_endian-llp64 shared (dynamic) release build; by GCC 10.2.0) on "windows"

It looks like all the tools have a higher version on MSys2. Should I be looking for anything else?

[jgehrig]

What's the issue here? You've got a working build, right?

Everything looks good, I'm still not sure exactly what is going wrong. Based on what you've described, my next best guess is %PATH% issues and the wrong tool version being selected.

In both cases gcc --version matches the qtdiag output. This is good.

[rashil2000]

What's the issue here? You've got a working build, right?

Everything looks good, I'm still not sure exactly what is going wrong. Based on what you've described, my next best guess is %PATH% issues and the wrong tool version being selected.

In both cases gcc --version matches the qtdiag output. This is good.

Yes, I've got a working build, I'm not denying that. But let's say I want to isolate whatever I've built and use it. What I'll do is, grab the nvim-qt.exe from the build/bin folder, and grab the contents of the build/windeployqt folder, and put these together.

Now, I double click the executable and launch it. For the first method (Qt Installer), everything works fine, neovim-qt launches.

But for the second method (Msys2), this procedure does not work. I get missing DLLs error when I try to double click the executable. To make this work, I have to copy those additional DLLs as shown in the screenshot.

[equalsraf]

At first glance the differences are:

• libbrotlicommon
• librotlidec
• libbz2
• libdouble-conversion
• libfreetype
• libglib
• libgraphite2
• libharfbuzz
• libiconv
• libicu
• libintl
• libpcre
• libpng
• libzstd
• zlib

I cannot verify this without looking into the msys2 Qt build - but a lot of these libraries are Qt dependencies and Qt supports building then internally or using available libraries.

My guess is that the Qt version built in msys2 is using separate dlls for these libraries instead of the version built inside Qt. This is a Qt build option,

This is the mingw qt5 build recipe

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-qt5/PKGBUILD#L10

I have not checked in detail but it seems there is a static and non-static variant and the later uses dlls built by other recipes.

This issue is not new, e.g. check this SO question.

[rashil2000]

Thanks for the detailed writeup @equalsraf!

I understand now.

For experiment's sake, I did install the mingw-w64-x86_64-qt5-static (it's a whopping 6GB installation) package through pacman and tried building the project. The build failed at some testing stage, but the nvim-qt.exe binary was produced (however, it was around 30MB in size as compared to the usual 3-4, possibly because it was statically bundling DLLs like Qt5Core, Qt5Gui, Qt5Network etc. inside the binary as expected). But again, I was not able to run it unless I copied those additional DLLs too.