To ease the maintenance of MinGW cross-compiling packages, I have written a new mingw.cygclass (actually, a series of cygclasses, but that's the top-level one that you should use) which is designed to allow building both 32- and 64-bit MinGW binaries in the same build. It also allows for the introduction of Windows for ARM toolchains, which I have bootstrapped but am not able to verify due to the lack of access to such systems. (Therefore, they are disabled by default.)
Because this moves fundamentally away from the single-arch paradigms on which cygport was built (remember that cygport predates the widespread availability of 64-bit Windows systems), extensive changes were required that could possibly break something. Therefore, I have posted this to the topic/mingw branch of cygport. If maintainers could please test this with both mingw and ordinary packages, that would be appreciated. Also needed is feedback on the naming schemes currently used: * mingw32_* functions and MINGW32_ definitions/variables for i686 * mingw64_* functions and MINGW64_ definitions/variables for x86_64 * mingwarm32_* functions and MINGWARM32_ definitions/variables for armv7 * mingwarm64_* functions and MINGWARM64_ definitions/variables for aarch64 * mingw-* for source package names * mingw64-i686-* for i686 binary packages * mingw64-x86_64-* for x86_64 binary packages * mingw64-armv7-* for armv7 binary packages * mingw64-aarch64-* for aarch64 binary packages The function/definition naming scheme is designed around Fedora (which does not have ARM, so I made those up myself) but the binary package scheme match our current usage. I realize the source package names are those from the old i686-only mingw.org packages; whether we want to rename the binary packages to mingw32-/mingw64-, or rename the source packages to mingw64-, or do something else entirely, I'm open to suggestions. -- Yaakov
