Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Mingw-w64.
Nothing was collected or created yet.
Mingw-w64
View on Wikipediafrom Wikipedia
| MinGW-w64 | |
|---|---|
| Original author | OneVision Software |
| Developers | Kai Tietz, Jonathan Yong, various GNU contributors |
| Initial release | 2005 |
| Stable release | 13.0.0
/ June 4, 2025 |
| Repository | sf |
| Written in | C, C++ |
| Operating system | Microsoft Windows, Linux, macOS |
| Type | Compiler |
| License | Public domain (headers), GNU General Public License (compiler and toolchain), Zope Public License |
| Website | mingw-w64 |
Mingw-w64 is a free and open-source suite of development tools that generate Portable Executable (PE) binaries for Microsoft Windows. It was forked in 2005–2010 from MinGW (Minimalist GNU for Windows).
Mingw-w64 includes a build of the GNU Compiler Collection (GCC) targeting the MinGW-w64 platform, GNU Binutils for Windows (assembler, linker, archive manager), a set of freely distributable Windows specific header files and static import libraries for the Windows API, a Windows-native version of the GNU Project's GNU Debugger, and miscellaneous utilities.
Mingw-w64 can be run natively on Microsoft Windows, cross-hosted on Linux (or other Unix), or "cross-native" on MSYS2 or Cygwin. Mingw-w64 can generate 32-bit and 64-bit executables for x86 under the target names i686-w64-mingw32 and x86_64-w64-mingw32.
History
[edit]In 2005, Mingw-w64 was created by OneVision Software under cleanroom software engineering principles, since the original MinGW project was not prompt on updating its code base, including the inclusion of several key new APIs and also much needed 64-bit support. In 2008, OneVision then donated the code to Kai Tietz, one of its lead developers, under the condition that it remain open source.[1] It was first submitted to the original MinGW project, but refused under suspicion of using non-public or proprietary information.[2][1][3] For many reasons, the lead developer and co-founder of the MinGW-w64 project, Kai Tietz, decided not to attempt further cooperation with MinGW.[4]
MinGW-w64 provides a more complete Win32 API implementation,[5] including:
- Better C99 support
- POSIX Threads (pthreads) support (including the possibility to enable C++11 thread-related functionality in GCC's libstdc++)
- GCC multilib, which allows users to install 32-bit and 64-bit libraries in parallel
- Unicode entry point (wmain/wWinMain)
- DDK (from ReactOS)
- DirectX (from Wine)
- Large file support
- Win64 support
- Structured Exception Handling (SEH) instead of DWARF or sjlj on x86-64 (from gcc 4.8+)
- Some useful tools such as
gendef(an improved version of MinGW'spexportsutility), andwidl(an MIDL compiler from Wine).
Additionally, the Mingw-w64 project maintains winpthreads, a wrapper library similar to pthreads-win32, with the main difference that it allows GCC to use it as a threads library resulting in functional C++11 thread libraries <thread>, <future>, and <mutex>.
MSYS2
[edit]MSYS2 ("minimal system 2") is a software distribution and a development platform for Microsoft Windows, based on Mingw-w64 and Cygwin, that helps to deploy code from the Unix world on Windows. It plays the same role the old MSYS did in MinGW.[6]
MSYS2 shares this goal of bringing Unix code to Windows machines with several other projects, most notably Cygwin and Windows Subsystem for Linux (WSL). WSL lets Linux ELF binaries run on Windows through a managed Virtual Machine. Cygwin provides a full POSIX environment (as a windows DLL) in which applications, compiled as Windows EXEs, run as they would under Unix.[7]
Instead of providing a full environment like Cygwin does, MSYS2 tasks itself with being a development and deployment platform.[8]
- There is a main MSYS2 environment (similar to, and in fact derived from, Cygwin's emulation code) with package manager and standard Unix system tool. This way, when managing MSYS2 itself, standard Unix tools can be used unmodified by using the emulated environment. It's also possible to install build tools in the MSYS2 emulated environment in case the user wants to build software that depends on the POSIX emulation layer instead of the native API.
- In addition, four environments are provided containing native compilers, build tools and libraries that can be directly used to build native Windows 32-bit or 64-bit programs. The final programs built with the two native environments don't use any kind of emulation and can run or be distributed like native Windows programs. The environments are MINGW64 and MINGW32 (the original MinGW-w64 environments using gcc, msvcrt, and libstdc++), UCRT64 (adaptation of MINGW64 to ucrt), and CLANG64 (adaptation of UCRT64 to clang and libc++). While Cygwin also provides MinGW-w64 compilers and libraries, the set of available libraries is smaller, and they are not as easily managed due to not being placed in separate prefixes.
The main MSYS2 environment provides a package manager (Pacman from Arch Linux), a bash shell, and other Unix programs. It uses a runtime library msys-2.0.dll (~20MB) that is derived from the Cygwin library cygwin1.dll, and is updated regularly to keep track of the Cygwin development. It is intended as a development environment, one that developers can manage (using pacman) and run their tools with. Features judged unnecessary for development are removed.[8]
As with Cygwin, MSYS2 supports path translation for non-MSYS2 software launched from it. For example one can use the command notepad++ /c/Users/John/file.txt to launch an editor that will open the file with the Windows path C:\Users\John\file.txt.[9][8]
MSYS2 and its bash environment is used by Git and GNU Octave for their official Windows distribution.
Compiler
[edit]Most languages supported by GCC are supported on the Mingw-w64 port as well. These include C, C++, Objective-C, Objective-C++, Fortran, and Ada. The GCC runtime libraries are used (libstdc++ for C++, libgfortran for Fortran, etc.). A packaging of LLVM's clang to mingw-w64 is also provided by MSYS2. It supports ARM for Windows (aarch64-w64-mingw32 and armv7-w64-mingw32).[10][11]
Binaries (executables or DLLs) generated with different C++ compilers (like Mingw-w64 GCC and Visual Studio) are in general not link compatible due to the use of different ABIs and name mangling schemes caused by the differences in C++ runtimes. However, compiled C code is link compatible.[12] Clang is an exception, as it mostly supports MSVC's C++ ABI on Windows.[13]
The binutils documentation has up-to-date information about its handling of various windows-specific formats and special tools for doing so.[14][15]
References
[edit]- ^ a b "(MinGW-w64) History". MinGW-w64 Wiki. Archived from the original on 2019-07-05. Retrieved 2016-02-18.
- ^ Danny Smith (13 August 2007). "Re: Sub project for w64 header & crt". Newsgroup: comp.gnu.mingw.devel. Usenet: 000001c7dd83$9ae74310$fe6d65da@THOMAS. Archived from the original on 23 July 2020. Retrieved 23 July 2020.
From a cursory spot check of a few files, the crt sources in particular appear to contain too much undocumented material that I suspect may be derived from proprietary sources. I have since avoided looking at the mingw-w64 sources to avoid any taint of copyright abuse. I could well be wrong, but I would rather be safe than jeopardise the future of the mingw32, which has tried to maintain a "clean-room" ethic during its development.
- ^ Marshall, Keith (19 July 2009). "Re: Harmonizing mingwrt / w32api with mingw-w64". MinGW-dvlpr (Mailing list). Archived from the original on 28 January 2020. Retrieved 12 June 2014.
However, we would require a formal audit of mingw-64 code, to ensure conformance with our requirements for truly open documentation of sources, before [merge of mingw-w64] could be completed.
- ^ Tietz, Kai (20 July 2014). "Re: Harmonizing mingwrt / w32api with mingw-w64". MinGW-dvlpr (Mailing list). Archived from the original on 28 January 2020. Retrieved 12 June 2014.
- ^ "MinGW-w64". MinGW-w64.org. Archived from the original on 18 October 2019. Retrieved 30 May 2013.
- ^ "MSYS2". www.msys2.org. Archived from the original on 2021-02-07. Retrieved 2022-09-30.
- ^ "ZSH on Windows via MSYS2". 26 July 2018. Archived from the original on 28 January 2020. Retrieved 30 January 2020.
- ^ a b c "How does MSYS2 differ from Cygwin · msys2/Msys2 Wiki". Archived from the original on 2023-02-15. Retrieved 2023-02-20.
- ^ Biswas, Supriyo (2017-04-29). "How to Get an Unix/Linux Environment on Windows with MSYS2". Boolean World. Archived from the original on 2022-09-30. Retrieved 2022-09-30.
- ^ "Package: mingw-w64-x86_64-clang". MSYS2 Packages. Archived from the original on 30 October 2020. Retrieved 12 February 2020.
- ^ Storsjö, Martin (23 April 2020). "mstorsjo/llvm-mingw". GitHub. Archived from the original on 29 November 2020. Retrieved 27 April 2020.
- ^ "Interoperability of Libraries Created by Different Compiler Brands". mingw.org. Archived from the original on 2020-11-30. Retrieved 2022-09-30.
- ^ "MSVC compatibility". Clang 11 documentation. Archived from the original on 2021-01-26. Retrieved 2020-02-12.
- ^ "ld: win32". sourceware.org. Archived from the original on 2020-02-14. Retrieved 2020-02-10.
- ^ "GNU Binary Utilities Documentation". sourceware.org. Archived from the original on 2020-02-19. Retrieved 2020-02-10.
External links
[edit]Mingw-w64
View on Grokipediafrom Grokipedia
Mingw-w64 is a free and open-source development platform that provides a comprehensive set of header files, import libraries, runtime libraries, and tools designed to enable the creation of native Windows applications and libraries when used alongside compiler toolchains such as GCC or LLVM, with support for 32-bit (x86), 64-bit (x86-64), and ARM64 architectures.[1][2]
Originating as a fork of the original MinGW project in 2007, Mingw-w64 was developed to address the limitations of its predecessor by incorporating 64-bit support and compatibility with newer Windows APIs, stemming from an initial effort in 2005 to port an Objective-C application to 64-bit Windows.[1][3] The project evolved from the need for a GCC-compatible environment that could target modern Windows systems beyond the 32-bit focus of early MinGW, which had been established to port GNU tools to Windows without requiring a POSIX emulation layer like Cygwin.[3]
Key features of Mingw-w64 include extensive Windows API headers exceeding one million lines, regularly updated to reflect evolving Microsoft APIs; runtime components such as Winpthreads for POSIX thread emulation in C++11 applications; and utilities like gendef for generating import libraries and widl for IDL compilation.[1] It is permissively licensed, allowing broad integration into various build environments, and is commonly distributed through package managers like MSYS2, which bundles it with GCC for streamlined installation on Windows.[4][5] Widely adopted for cross-compilation and native Windows development, Mingw-w64 facilitates the production of standalone executables without additional runtime dependencies, making it a staple in open-source software packaging for Windows platforms.[2]
Overview
Definition and Purpose
Mingw-w64 is a free and open-source software development toolchain that serves as a fork and extension of the original MinGW project, providing a complete runtime environment for the GCC compiler to generate native 32-bit and 64-bit Windows executables.[2][1] It consists of header files, import libraries, runtime libraries, and tools designed to work with GCC or other compatible compilers like LLVM/Clang, enabling developers to build standalone Portable Executable (PE) binaries for Microsoft Windows without external dependencies.[1] The primary purpose of Mingw-w64 is to facilitate the development of native Windows applications by allowing direct access to the Windows API, which supports the creation of high-performance software such as games, system utilities, and other performance-critical programs.[2] It enables cross-compilation from various host platforms (including Linux and macOS) to Windows targets, streamlining the process for developers who need to produce Windows-specific code without relying on proprietary tools.[6] Mingw-w64 offers full support for x86 (32-bit) and x86-64 (64-bit) architectures, with support for ARM and AArch64 targets on Windows, allowing for broader compatibility across Windows hardware ecosystems.[6] Unlike POSIX-emulating environments such as Cygwin, Mingw-w64 produces pure native Windows binaries that do not require a separate runtime layer, ensuring smaller footprints and optimal integration with the Windows operating system.[2]Key Features and Capabilities
Mingw-w64 provides comprehensive multi-architecture support, enabling the development of native Windows applications for both 32-bit (Win32) and 64-bit (Win64) x86 architectures through dedicated headers and libraries.[1] It includes runtime libraries, with the Universal C Runtime (UCRT)—introduced in Windows 10 and the default since Mingw-w64 v12.0.0 in 2024—for enhanced portability and modern API access, as well as support for the older Microsoft Visual C Runtime (MSVCRT) for broader compatibility across Windows versions.[7][8] This runtime configuration allows developers to target contemporary systems while maintaining backward compatibility without requiring separate toolchains.[6] In terms of standards compliance, Mingw-w64 leverages the GNU Compiler Collection (GCC) to deliver full support for the C11 standard and C++17, with partial implementation of C++20 features, ensuring adherence to ISO specifications for modern language constructs.[9] POSIX threads (pthreads) are implemented natively via the Win32 API, facilitating portable multithreading code that aligns with Unix-like environments while operating seamlessly on Windows.[1] The project's headers, exceeding a million lines, actively track evolving Windows APIs to maintain compliance with platform-specific extensions.[1] Exception handling in Mingw-w64 incorporates Structured Exception Handling (SEH), Microsoft's native mechanism for C++ exceptions, which ensures interoperability with tools like Microsoft Visual C++ (MSVC) by using table-based unwinding in 64-bit mode and stack-based in 32-bit.[10] This integration allows mixed-language projects to propagate exceptions across boundaries without runtime mismatches, enhancing reliability in Windows-specific error scenarios such as hardware faults.[11] The default threading model employs Winpthreads, a POSIX-compliant library built atop Win32 threads, providing full C++11 and C11 threading primitives like std::thread while minimizing overhead through native API calls.[1] Developers can opt for the native Windows threading model (win32) for lighter-weight applications that avoid POSIX emulation, configurable during toolchain builds to suit performance or portability needs.[11] Mingw-w64 integrates tightly with MSYS2, a build environment that employs the pacman package manager for straightforward dependency resolution, installation, and updates of libraries and tools essential for Windows-native development.[12] This synergy simplifies workflows by treating Mingw-w64 components as packages within MSYS2's repositories, enabling automated handling of cross-dependencies without manual configuration.[13]History
Origins and Relation to MinGW
The MinGW project, short for Minimalist GNU for Windows, originated in the late 1990s as an effort to port the GNU Compiler Collection (GCC) and related tools to Microsoft Windows, enabling the creation of native Windows executables without the POSIX emulation layer required by Cygwin.[14] This initiative, initially led by Colin Peters and later maintained by Mumit Khan and a broader developer group via SourceForge, provided freely distributable import libraries and header files to support building 32-bit Windows applications using open-source tools.[15] The core aim was to deliver a lightweight development environment that integrated GNU software directly with the Windows API, avoiding the overhead of Unix-like subsystems.[15] Despite its successes, the original MinGW faced significant limitations, particularly its restriction to 32-bit architectures and incomplete support for the evolving Windows API, including newer interfaces beyond those documented in MSDN at the time.[3] These constraints became increasingly problematic by the mid-2000s, as 64-bit computing gained traction with the release of Windows XP 64-bit and subsequent versions, limiting MinGW's applicability for modern Windows development and leading to community dissatisfaction with its sourcing policies that mandated MSDN-derived contributions only.[3] The project traces its roots to 2005, when developers at OneVision Software began work to port an Objective-C application to 64-bit Windows using a GCC-based toolchain.[3] To address these gaps, the Mingw-w64 project emerged in 2007 as a community-driven fork of MinGW, spearheaded by developers at OneVision Software who aimed to introduce x86-64 compatibility and enhance overall maintainability through better tracking of Windows API updates.[1] The fork was motivated by the need to support 64-bit Windows natively while preserving MinGW's minimalist philosophy, following the original project's rejection of OneVision's initial work in 2007 due to suspicions of proprietary code influences.[3] The project was registered on SourceForge in August 2007, with a public repository available by October, marking the beginning of independent development focused on cross-architecture portability.[3] Key early contributors included Kai Tietz, who assumed maintenance responsibilities in 2008 after OneVision donated the codebase, solidifying its open-source foundation and guiding initial technical integrations.[3] The Rubenvb community played a role in the nascent stages by establishing repository structures and distributing early pre-built toolchains, which helped bootstrap user adoption and testing of the fork's capabilities.Major Developments and Milestones
The Mingw-w64 project achieved its first stable releases between 2008 and 2010, marking a pivotal shift toward robust x86-64 support that addressed limitations in the original MinGW's 32-bit focus.[3] In 2008, following the donation of initial code by OneVision Software to maintainer Kai Tietz, the project stabilized its runtime environment, enabling native 64-bit Windows compilation with GCC.[3] Early versions around 2010-2012 introduced comprehensive x86-64 headers and libraries, with the Winpthreads library for POSIX thread emulation on Windows added in version 3.0.[8] Around 2019, with projects like llvm-mingw, LLVM/Clang was adopted as an alternative compiler backend, broadening Mingw-w64's compatibility beyond GCC and facilitating faster iteration on Windows-specific optimizations.[16] This integration allowed developers to leverage Clang's diagnostics and modular design while using Mingw-w64's runtime, with initial builds targeting both 32-bit and 64-bit architectures.[16] From 2016 to 2020, Mingw-w64 saw enhanced support for ARM architectures and integration with the Universal C Runtime (UCRT), aligning closely with Windows 10's ecosystem updates. Version 5.0.0 in 2016 added updates to DirectX headers; ARM support was introduced in earlier version 4.0, with further refinements in subsequent releases. Windows 10 API support, including UCRT, was enhanced starting in version 6.0.0 (2018), enabling cross-compilation for ARM-based Windows devices.[8] Versions 7.0.0 (2019) and 8.0.0 (2020) further refined ARM math libraries and extended UCRT to Windows Store apps, improving binary distribution on modern hardware.[8] Recent updates through 2025 have focused on modern language standards and security enhancements, with version 10.0.0 (2022) incorporating GCC 11 compatibility for improved C++20 compliance, including modules and coroutines via upstream GCC advancements.[8] Versions 11.0.0 (2023) and beyond introduced Control Flow Guard and elevated _FORTIFY_SOURCE levels to 3, providing better mitigations against Spectre and Meltdown vulnerabilities through fortified buffer checks and indirect branch predictions.[8] By version 13.0.0 in June 2025, CI/CD automation was streamlined in the project's repositories, with automated testing for UCRT defaults and ARM64EC targets to ensure reliable builds.[8] Project governance has evolved to emphasize community-driven maintenance, with a shift to GitHub mirroring around 2015 for easier collaboration, while primary development remains volunteer-led on SourceForge.[17] This structure supports ongoing contributions from GNU toolchain developers, ensuring alignment with upstream projects without centralized oversight.[10]Components
GCC Compiler Integration
MinGW-w64 integrates the GNU Compiler Collection (GCC) by supplying a comprehensive set of Windows-specific headers, import libraries, and runtime components that enable GCC to produce native Portable Executable (PE) binaries for Windows, supporting both 32-bit (i686) and 64-bit (x86_64) architectures as well as ARM variants. This integration allows developers to compile POSIX-compliant code that interfaces directly with the Windows API without requiring a POSIX emulation layer.[1] MinGW-w64 typically supports GCC versions from 8.x onward, with pre-built toolchains incorporating the latest stable releases such as GCC 15.1.0 or 15.2.0 as of late 2025; these builds often include targeted patches to align with Windows ABI conventions, including the Microsoft x64 calling convention (ms_abi) and structured exception handling (SEH). For instance, patches ensure proper handling of Windows-specific attributes like __declspec(dllimport) and compatibility with the Itanium C++ ABI used in mingw-w64.[6] To target specific architectures, MinGW-w64 leverages GCC flags such as -m32 for 32-bit x86 code generation and -m64 for 64-bit x86_64, while -march=native optimizes for the host CPU's features, including SSE/AVX instructions when available on Windows hosts. Additional options like -municode enable Unicode support by defining the UNICODE macro and selecting appropriate runtime startup code for MinGW-w64 targets. These flags facilitate cross-compilation from non-Windows hosts or native builds on Windows. The runtime environment relies on mingwrt, the core MinGW runtime library, which provides essential C library functions and wrappers for Windows system calls (e.g., via ntdll.dll and kernel32.dll), bridging standard C/POSIX interfaces to Win32 APIs for direct syscall invocation without overhead. Programs compiled with GCC link dynamically or statically to mingwrt, ensuring compatibility with Windows 7 and later versions.[18] The build process for GCC in MinGW-w64 contexts uses standard GNU configure scripts, specifying the target triplet like --target=x86_64-w64-mingw32 for 64-bit Windows executables, which configures the compiler, assembler, and linker to generate PE/COFF output formats suitable for Windows deployment. This setup supports multilib configurations for simultaneous 32-bit and 64-bit builds from a single toolchain. Debugging support is provided through seamless integration with the GNU Debugger (GDB), which attaches to Windows processes compiled by GCC, handling MinGW-w64-specific symbol formats such as DWARF debug information embedded in executables via the -g flag. GDB in MinGW-w64 toolchains supports breakpoints, watchpoints, and stack traces for native Windows applications, including multi-threaded programs using Winpthreads, with options for remote debugging over Windows debug APIs.MSYS2 Build Environment
MSYS2 serves as a software distribution and building platform for Windows, providing a Unix-like environment through a bash shell and essential Unix tools such as tar, awk, and git, all facilitated by the Pacman package manager inspired by Arch Linux.[13][19] This setup enables developers to manage dependencies and build software in a POSIX-emulating shell without relying on heavier alternatives like Cygwin. Originally evolving from the earlier MSYS project tied to MinGW, MSYS2 has become the preferred build environment for Mingw-w64, offering streamlined workflows for native Windows application development.[20] In integration with Mingw-w64, MSYS2 maintains separate environments to support targeted builds and prevent path conflicts, including MINGW32 for 32-bit native Windows applications, MINGW64 for 64-bit builds using the MSVCRT runtime, and UCRT64 for 64-bit builds leveraging Microsoft's Universal C Runtime.[20][5] Each environment uses distinct directory prefixes (e.g., /mingw64 or /ucrt64) and isolated toolchains, allowing seamless switching via dedicated shell launchers like mingw64.exe or ucrt64.exe, while inheriting POSIX emulation from the base MSYS subsystem for build processes.[20] The MSYS2 package ecosystem encompasses over 10,000 pre-built packages across its repositories, including cross-platform libraries such as SDL for multimedia and Boost for C++ utilities, all specifically compiled for Mingw-w64 targets to simplify dependency resolution during development.[21][12] These packages cover build tools, runtimes, and headers, enabling rapid prototyping and deployment of Windows-native binaries without manual compilation of dependencies. MSYS2 employs a rolling-release model, where the base system and packages update frequently via Pacman commands like pacman -Syu, ensuring access to the latest Mingw-w64 toolchains and security patches in an Arch Linux-inspired manner.[22] A key limitation of MSYS2 is that its POSIX emulation applies primarily to build-time operations within the shell, not to the runtime of the final Mingw-w64 binaries, which remain native Windows executables free from any emulation overhead.[20]Additional Toolchains and Libraries
Mingw-w64 extends its toolchain beyond the primary GCC integration by incorporating support for alternative compilers such as Clang from the LLVM project. Official distributions, particularly through MSYS2, have provided Clang/LLVM-based builds since 2016, enabling developers to compile Windows-native applications using Clang's frontend and LLVM's backend.[23] These builds leverage the LLD linker, which offers significantly faster linking times compared to traditional GNU ld, especially for large projects, while maintaining compatibility with Windows PE/COFF formats.[16] To target Mingw-w64 environments, developers specify flags like--target=x86_64-w64-mingw32 for 64-bit Windows or --target=i686-w64-mingw32 for 32-bit, allowing seamless cross-compilation from Linux or other hosts.[16]
The project also includes customized versions of GNU Binutils, which provide essential utilities for assembling and linking object files tailored to Windows. The GNU assembler (as) and linker (ld) in Mingw-w64 are adapted to handle the Portable Executable (PE) and Common Object File Format (COFF) binaries required for Windows executables and dynamic libraries.[24] These tools support features like generating import libraries and resolving Windows-specific symbols, ensuring that object files produced on non-Windows hosts are fully compatible with the Windows runtime.[25]
Runtime libraries in Mingw-w64 supply comprehensive headers and implementations for key Windows APIs, facilitating development without relying on proprietary SDKs. This includes headers for DirectX, enabling graphics and multimedia programming with official open-source distributions under the MIT license, and WinSock for network socket operations, which mirror the Windows Sockets API for TCP/IP communication.[26] Additionally, the msys-2.0.dll provides an optional POSIX runtime layer, primarily for development and build environments, offering compatibility with Unix-like tools while allowing binaries to remain lightweight by excluding it in final distributions.[27]
Integration with Wine enhances Mingw-w64's utility for cross-compilation workflows, particularly on Linux hosts. Developers can build Windows binaries using Mingw-w64 and immediately test them under Wine, which emulates the Windows API to run PE executables natively on Unix systems, aiding in debugging and validation without a full Windows installation. This setup is commonly used for iterative testing during cross-compilation, with tools like Wine's WIDL (a reimplementation of Microsoft's IDL compiler) supporting interface definitions for COM and RPC components.
Mingw-w64 provides support for AArch64 (ARM64) targets, allowing compilation of applications for Windows on ARM devices. This capability, available in recent runtimes and toolchains, pairs with QEMU for emulation, enabling developers to test ARM Windows binaries on x86 hosts by simulating the ARM architecture and Windows environment.[28] MSYS2 packages these ARM tools, providing a complete ecosystem for building and emulating ARM64 Windows software.[29]
Usage
Installation Procedures
Mingw-w64 can be installed on Windows through several methods, including standalone pre-built toolchains and bundled environments like MSYS2. For standalone installations, users download archive files from trusted providers listed on the official Mingw-w64 website, such as those hosted on SourceForge or third-party builds like WinLibs.[6][2] To obtain a standalone toolchain, select the appropriate architecture (x86_64 for 64-bit or i686 for 32-bit), threading model (win32 for native Windows threads or posix for POSIX-compatible threads), and exception handling (seh for Structured Exception Handling, native to Windows, or sjlj for setjmp/longjmp-based handling, which offers better compatibility but higher overhead).[6][30] Download the corresponding .zip or .7z archive, extract it to a directory like C:\mingw64, and add the bin subdirectory (e.g., C:\mingw64\bin) to the system PATH environment variable to make tools like gcc accessible from the command prompt.[6][31] For a more comprehensive setup, especially on Windows, MSYS2 provides a bundled environment with Mingw-w64. Download the latest installer (msys2-x86_64-latest.exe) from the official MSYS2 website and run it to install to a directory like C:\msys64.[13] After installation, launch the MSYS2 terminal from the Start menu, update the package database withpacman -Syu, close and reopen the terminal if prompted, then run pacman -Syu again to complete updates. Install the Mingw-w64 GCC package with pacman -S mingw-w64-ucrt-x86_64-gcc (for UCRT runtime) or similar variants for other environments like MINGW64 or CLANG64.[32][5]
For cross-compilation from Linux hosts, MXE offers a build environment that compiles a Mingw-w64 cross-compiler and libraries. Clone the MXE repository from GitHub, install prerequisites like make and autoconf via the host system's package manager, then run make from the root directory of the cloned repository to build the toolchain, specifying targets like x86_64-w64-mingw32.static for static linking. Pre-built MXE packages are available for direct use.[33][34]
To verify installation, open a command prompt or MSYS2 terminal, run gcc --version to confirm the GCC version and Mingw-w64 target (e.g., x86_64-w64-mingw32), and in MSYS2, use echo $MSYSTEM to check the active environment (e.g., UCRT64).[35][5]
Common pitfalls include incorrect PATH configuration, where Mingw-w64 binaries conflict with system or other toolchain tools; prioritize the Mingw-w64 bin path by placing it first in the PATH variable and restarting the shell. Multiple installations can lead to version mismatches, so use environment-specific terminals in MSYS2 (e.g., MSYS2 UCRT64) to isolate toolchains.[31][36]
Project Compilation and Configuration
Mingw-w64 supports straightforward compilation of C and C++ projects using the GCC compiler integrated within its toolchain. For a basic single-file program, such as a "Hello World" example, the commandgcc hello.c -o hello.exe compiles the source file into an executable suitable for Windows.[31] To include header files from the Mingw-w64 environment, specify paths with the -I flag, for instance -I/mingw64/include when working in an MSYS2 shell.
Integration with build systems enhances project management in Mingw-w64. CMake, a popular cross-platform build generator, can be configured for native Windows builds by invoking cmake -G "MinGW Makefiles" .. from the build directory, which generates Makefiles compatible with the Mingw-w64 GCC. For more complex setups, especially cross-compilation, a toolchain file defines compiler paths and system specifics; an example file might set set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc) and set(CMAKE_SYSTEM_NAME Windows) to target 64-bit Windows.[37] Make and Ninja are also supported via MSYS2, where make executes standard GNU Makefiles, and Ninja offers faster parallel builds when generated by CMake with -G Ninja.[38]
Configuration options allow customization of linking behavior and resource handling. To produce a dynamic link library (DLL), use gcc -shared -o mylib.dll source.c, which creates a shared object importable by other programs. For static linking, append -static to the command, embedding dependencies like the C runtime directly into the executable to reduce runtime DLL requirements: gcc -static -o program.exe source.c. Windows resources, such as icons or version information in .rc files, are compiled separately using windres resource.rc -o resource.o, with the resulting object file linked into the final executable via gcc source.c resource.o -o program.exe.[39]
Cross-compilation from Linux distributions like Ubuntu enables building Windows binaries without a Windows host. Install the toolchain via sudo apt install mingw-w64, then compile with the prefixed compiler x86_64-w64-mingw32-gcc hello.c -o hello.exe for 64-bit targets. This setup leverages the same GCC flags as native builds, ensuring compatibility across environments.
Common troubleshooting involves resolving linker errors, often due to missing Windows API libraries. For instance, undefined references to functions like MessageBox require explicit linking with -luser32: gcc source.c -o program.exe -luser32. To mitigate DLL version conflicts (DLL hell), embed a manifest file in the executable during linking with windres, specifying assembly identity for side-by-side execution; this ensures the correct runtime versions are loaded.
Comparisons and Alternatives
Differences from Original MinGW
Mingw-w64 diverges from the original MinGW project primarily in its expanded architecture support, enabling compilation for both 32-bit x86 and 64-bit x64 Windows systems, as well as ARM architectures, whereas the original MinGW is limited to 32-bit x86 targets only.[1][40] This multilib capability in Mingw-w64 allows developers to build both 32-bit and 64-bit programs within a single environment using GCC 4.5 and later versions.[40] In terms of maintenance, the original MinGW project has been largely inactive since its last major release in 2013, with no significant updates to integrate modern GCC versions beyond 4.8.[41] In contrast, Mingw-w64 remains actively developed, incorporating the latest GCC releases and automated toolchain builds to ensure compatibility with contemporary Windows features.[1][40] Mingw-w64 provides broader API coverage through over a million lines of Windows headers, including support for newer interfaces such as Windows Vista and Windows 7 APIs, DirectX, and Device Driver Kit (DDK), which are absent or incomplete in the original MinGW's more limited header set derived from older w32api sources.[1] It also offers improved Unicode handling via the "-municode" compiler switch (available in GCC 4.5+), enabling MS-style Unicode applications, unlike the original MinGW's basic ASCII-focused support.[40] For threading, Mingw-w64 includes Winpthreads, a POSIX-compatible threading library that supports C++11 standards and thread-local storage callbacks, eliminating the need for the deprecated mingwm10.dll used in the original MinGW for basic exception handling and limiting its threading options.[1][40] These enhancements result in compatibility differences, where Mingw-w64 binaries may not run on pure original MinGW setups due to divergent runtimes, math libraries (offering better conformance than Microsoft Visual Studio in some cases), and optional Windows Store compatibility layers like Winstorecompat.[1] The project originated as a 2007 fork of MinGW to address these gaps, particularly the lack of 64-bit support.[1]Contrasts with Cygwin
MinGW-w64 and Cygwin serve as open-source environments for compiling C and C++ code on Windows using the GNU Compiler Collection (GCC), but they diverge significantly in their architectural philosophies: MinGW-w64 emphasizes native Windows integration, while Cygwin prioritizes POSIX compatibility through emulation.[42][43] A primary distinction lies in runtime dependencies. Programs compiled with MinGW-w64 produce standalone executables that link directly to the native Windows runtime (such as msvcrt.dll) and the Win32 API, requiring no additional DLLs beyond standard Windows components for distribution.[1] In contrast, Cygwin applications depend on the cygwin1.dll library to emulate POSIX system calls, necessitating that this DLL be present on the target system for the executables to run.[43] Performance characteristics also differ due to these approaches. MinGW-w64 enables faster execution for Windows-specific code by invoking native API calls without intermediary translation, avoiding the overhead inherent in Cygwin's POSIX emulation layer, which can introduce latency in syscall handling.[42][43] In terms of portability, Cygwin simplifies the adaptation of Unix software to Windows by offering a near-complete POSIX environment, making it suitable for minimal-modification ports, though the emulation reduces efficiency on the host platform. MinGW-w64, however, is optimized for creating applications that are fully native to Windows, supporting both 32-bit and 64-bit architectures with direct compatibility to Windows APIs but requiring more adjustments for pure Unix codebases.[43][42] Toolsets overlap in providing GCC and related GNU tools, but Cygwin extends this with a full suite of runtime-dependent Unix utilities (such as bash, grep, and awk) that leverage its POSIX layer. MinGW-w64, paired with environments like MSYS2, maintains a leaner set focused on native Windows development, without embedding a comprehensive Unix toolchain in the produced binaries.[42][43] These contrasts influence typical use cases. MinGW-w64 is favored for developing performance-sensitive native Windows applications, such as games and system tools, where dependency-free distribution and direct OS integration are advantageous. Cygwin, conversely, suits scenarios requiring POSIX compliance, like porting server software or running bash-based scripts in a Unix-like setting on Windows.[1][43]Relation to Microsoft Visual Studio
Mingw-w64 employs the GCC compiler, which adheres to the Itanium C++ Application Binary Interface (ABI), in contrast to Microsoft Visual C++ (MSVC), which utilizes a proprietary ABI. This divergence results in general incompatibility for linking C++ object files or binaries between the two, particularly with features like templates and exception handling, though C code maintains ABI compatibility on Windows due to shared use of the Microsoft C runtime.[44][45] Interoperability with Microsoft Visual Studio is facilitated through lightweight integration rather than native project support. In Visual Studio (version 15.3 and later), Mingw-w64 can be used via the "Open Folder" feature, enabling IntelliSense, building, and debugging of GCC-based projects configured with JSON files likec_cpp_properties.json and tasks.json. For Visual Studio Code, the official C/C++ extension provides seamless setup for Mingw-w64, including compiler path configuration and GDB debugging, without requiring Visual Studio installation. However, full Visual Studio project (.vcxproj) compatibility demands third-party extensions, as Mingw-w64 lacks direct support for MSBuild.[46][31]
Linking MSVC-compiled object files or DLLs with Mingw-w64 is feasible for C interfaces but requires careful management to avoid ABI mismatches, often involving the creation of shim libraries with exported C functions and alignment of runtime options, such as using the multithreaded DLL runtime (msvcrt.dll) via flags like -D__USE_MINGW_ANSI_STDIO. C++ linking typically demands recompilation or wrappers due to name mangling differences.[47]
As a free and open-source alternative to the proprietary Visual Studio toolchain, Mingw-w64 offers cross-platform development capabilities, allowing Windows binaries to be built from Linux hosts, which enhances CI/CD pipelines. Drawbacks include potentially slower compilation times compared to MSVC, especially for large projects, and less optimized debug performance on Windows-specific code. Hybrid workflows commonly leverage Mingw-w64 for automated, cross-platform builds in CI/CD environments while using Visual Studio for interactive GUI-based development and testing.[1][48]