MinGW package guidelines

This page expains how to write PKGBUILDs for software running on Windows using GCC. There are two options to build software for Windows on Linux:

• mingw-w64: provides 32 and 64-bit toolchains with secure crt, Vista+ API, DDK (ReactOS), and DirectX (WINE) support. For a full list of supported features and differences with the old MinGW.org, see here. Available from the official repositories by installing mingw-w64-gcc.
• MinGW: provides 32-bit toolchains with limited DirectX support. It also suffers from long-standing breakage in the implementation of thread-local storage and the floating point library support. It has been removed from the official repositories and the AUR.

Arch package guidelines

---

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Font – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – Shell – VCS – Web – Wine

Package naming

A package for mingw-w64 should be named mingw-w64-pkgname. If a static variant of the package is being built, suffix the package name with -static (see below for the cases where this is necessary).

Packaging

Packaging for cross platform packages can be fairly tricky as there are many different build systems and low-level quirks. Take a note of the following things though:

• always add mingw-w64-crt to depends, unless it depends on another package which implicitly depends on it
• always add mingw-w64-gcc to makedepends, unless using mingw-w64-configure^AUR or mingw-w64-cmake^AUR
• always add !strip, and !buildflags to
• always use the original and append to the end of
• always use and follow the original of the official package
• always build both 32-bit and 64-bit versions of libraries
• always put all stuff under the /usr/i686-w64-mingw32 and prefix
• always use as the architecture (except the package contains executables which must run on the build system)
• always build both shared and static libraries
  • autotools-based projects often support building both in one go, when using mingw-w64-configure^AUR shared and static libraries are both enabled
  • if the build system or project does not support this, build both separately
  • if the shared and static build conflict (e.g. because headers or CMake configuration files differ) consider installing static libraries into and
  • for bigger projects, consider creating a separate -static package
• consider removing unneeded documentation (, )
• consider using mingw-w64-configure^AUR for building with configure scripts
• consider using mingw-w64-cmake^AUR for building with CMake
• consider using for building with Meson
• consider using mingw-w64-make^AUR for building with raw Makefiles
• consider using for building with QMake
• consider explicitly stripping symbols with ${_arch}-strip in 's for-loop as demonstrated in the below PKGBUILD examples.
  • consider using the find command to iterate over since not all DLLs, static libraries, or executables may reside in their appropriate locations.
    • if the binary is a DLL, use
    • if the binary is a static lib, use
• if a package is modular (requires certain build dependencies, but said dependencies are optional to the end user) add these to makedepends and . Be sure to subtract them from depends if updating an existing package. Example of this in use:
• if a package installs a script, symlink it to $pkgdir/usr/bin/${_arch}-*-config
• if a package uses autoconf, explicitly set for to workaround autoconf bug #108405 or use mingw-w64-configure^AUR

As mentioned above, the files should all be installed into /usr/i686-w64-mingw32 and . Specifically, all DLLs should be put into as they are dynamic libraries needed at runtime. Their corresponding .dll.a files should go into . Please delete any unnecessary documentation and perhaps other files from . Cross-compilations packages are not meant for the user but only for the compiler and binary distribution, and as such you should try to make them as small as possible.

Always try to match the in your mingw-w64 packages to the of the corresponding regular packages in the official Arch Linux repos (not the testing repos). This ensures that the cross-compiled software works exactly the same way on Windows without any unexpected bugs. If packages in Arch are out-of-date, there usually is a good reason and you should still follow the Arch version instead of using the most recent upstream release. If the corresponding native package is in the AUR, you need not follow this version policy, as many AUR packages are often orphaned or left unmaintained.

Examples

The following examples will try to cover some of the most common conventions and build systems.