What is the MinGW-w64 Toolchain?

MinGW-w64 itself is a package providing headers, C runtime libraries, and much more. When support for it is built into compilers such as GCC, it enables the building of software targetting Windows, such as programs and libraries. This software is aimed to be used on Windows, but can also be used on Linux.

Wine-10.7 depends on this functionality to build DLLs (Dynamic Link Libraries), or the equivalent of Linux dynamic libraries, appended with the suffix .so, or Shared Objects.

A lot of Windows software is dynamically linked. While most of them when shipped include DLLs packaged in the installed directory, or extracted from a ZIP file, not all DLLs will be packaged as a number will be installed on a given Windows machine already, such as libraries for DirectX/Direct3D support. Since we are on a Unix-like operating system, we do not have such DLLs installed on the system, and they were never compiled in LFS or earlier in this book. NVIDIA-575.51.02 does install two DLL files but are strictly meant for Wine and Proton. MinGW-w64 does not install these libraries, so Wine needs to compile them for most Windows software to function.

If you are a developer and wish to target Windows, this toolchain should be pretty useful. You won't need to follow any of the chapters after this one if you just want the MinGW-w64 toolchain. It is recommended to still install Wine for sanity checks revolving around your built software you are developing, although it isn't a perfect replacement for an accurate Windows environment. While the built software may work fine with Wine, it could be totally broken on Windows. An example is linking against libraries installed by Wine or MinGW-w64 and Windows complaining that Unixlib can not be found.

The following process works up to building the pieces for a static compilation of GCC, which means it cannot do much of anything with dynamic libraries besides build them. This is especially a problem with C++ software as you need libstdc++, which should be dynamic, for linking and execution. This is also a problem for software that uses atomic. Most of all, Windows software built with the toolchain needs libgcc_s_seh which is not provided in the static build.

However, this barebones basic toolchain is enough to build up the remaining pieces of the toolchain. After doing so, you can rebuild GCC and have a complete toolchain ready for targetting Windows. Realistically, you could grab a binary distribution of the toolchain and compile everything with less steps. In the past, that is exactly what this book has done. GLFS editors/contributors since then have decided to scrap that idea ^[14] and have chosen to bootstrap the toolchain instead.