* [[#MinGW-w64|[mingw-w64.sourceforge.net&#93;]]: 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 [http://sourceforge.net/apps/trac/mingw-w64/wiki/Feature%20list here]. Available in the [[AUR]] by installing {{AUR|mingw-w64-gcc}}

+

* [[#MinGW-w64|[mingw-w64.sourceforge.net&#93;]]: 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 [http://sourceforge.net/apps/trac/mingw-w64/wiki/Feature%20list here]. Available from Arch's [[#.5Bcommunity.5D|[community]]] repository by installing {{Pkg|mingw-w64-gcc}}.

+

* [[#MinGW.org|[www.MinGW.org&#93;]]: provides 32-bit toolchains with limited DirectX support. Available in the [[AUR]] by installing {{AUR|mingw32-gcc}}

There are some differences between the packaging of both projects, detailed below.

There are some differences between the packaging of both projects, detailed below.

Line 12:

Line 13:

=== Package naming ===

=== Package naming ===

−

A package for mingw-w64 should be named {{Ic|mingw-w64-''pkgname''}}. In the case that a package is 32-bit only, prefix the package name with {{Ic|lib32-}}. If a static variant of the package is being built, suffix the package name with {{ic|-static}}.

+

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

=== Packaging ===

=== Packaging ===

Line 26:

Line 27:

* always use {{ic|any}} as the architecture

* always use {{ic|any}} as the architecture

* always build both shared and static binaries, unless they conflict

* always build both shared and static binaries, unless they conflict

−

* always remove Win32 executables (*.exe) if the intended package is a library

** if the binary is a DLL, use {{ic|${_arch}-strip --strip-unneeded *.dll}}

+

** consider using the `find` command to iterate over {{ic|$pkgdir}} since not all DLLs, static libraries, or executables may reside in their appropriate locations.

−

** if the binary is a static lib, use {{ic|${_arch}-strip -g *.a}}

+

*** if the binary is a DLL, use {{ic|${_arch}-strip --strip-unneeded *.dll}}

+

*** if the binary is a static lib, use {{ic|${_arch}-strip -g *.a}}

+

* if a package is modular (requires certain build dependencies, but said dependencies are optional to the end user) add these to {{ic|makedepends}} and {{ic|optdepends}}. Be sure to subtract them from {{ic|depends}} if updating an existing package. Example of this in use: {{AUR|mingw-w64-ruby}}, {{AUR|mingw-w64-allegro}}

+

* if a package installs a {{ic|$pkgdir/usr/${_arch}/bin/*-config}} script, symlink it to {{ic|$pkgdir/usr/bin/${_arch}-*-config}}

−

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

+

As mentioned above, the files should all be installed into {{Ic|/usr/i686-w64-mingw32}} and {{Ic|/usr/x86_64-w64-mingw32}}. Specifically, all DLLs should be put into {{Ic|/usr/*-w64-mingw32/bin}} as they are dynamic libraries needed at runtime. Their corresponding {{Ic|.dll.a}} files should go into {{Ic|/usr/*-w64-mingw32/lib}}. Please delete any unnecessary documentation and perhaps other files from {{Ic|/usr/share}}. 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 {{Ic|pkgver}} in your mingw-w64 packages to the {{Ic|pkgver}} 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.

+

Always try to match the {{Ic|pkgver}} in your mingw-w64 packages to the {{Ic|pkgver}} 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.

Revision as of 13:25, 20 November 2013

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.sourceforge.net]: 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 Arch's [community] repository by installing mingw-w64-gcc.

consider explicitly stripping symbols with ${_arch}-strip in package()'s for-loop as demonstrated in the below PKGBUILD examples.

consider using the `find` command to iterate over $pkgdir since not all DLLs, static libraries, or executables may reside in their appropriate locations.

if the binary is a DLL, use ${_arch}-strip --strip-unneeded *.dll

if the binary is a static lib, use ${_arch}-strip -g *.a

if a package is modular (requires certain build dependencies, but said dependencies are optional to the end user) add these to makedepends and optdepends. Be sure to subtract them from depends if updating an existing package. Example of this in use: mingw-w64-rubyAUR, mingw-w64-allegroAUR

if a package installs a $pkgdir/usr/${_arch}/bin/*-config script, symlink it to $pkgdir/usr/bin/${_arch}-*-config

As mentioned above, the files should all be installed into /usr/i686-w64-mingw32 and /usr/x86_64-w64-mingw32. Specifically, all DLLs should be put into /usr/*-w64-mingw32/bin as they are dynamic libraries needed at runtime. Their corresponding .dll.a files should go into /usr/*-w64-mingw32/lib. Please delete any unnecessary documentation and perhaps other files from /usr/share. 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 pkgver in your mingw-w64 packages to the pkgver 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.

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

Always try to match the pkgver in your mingw packages to the pkgver 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 mingw 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.

Examples

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