MINGW-packages

MSVC is the main target for windows for qt5. They do provide a mingw version to support the community of devs and are great for accepting code upstream. With most projects however mingw targets are often somewhat neglected and broken even with release versions in some subtle ways. Our Mingw packages are actually used more broadly by devs on a daily basis and tested regularly by a package manager with other projects that depend on qt5. Fixes end up in msys2 before they reach qt5 upstream because of that, some times we have too many as you can see here. https://github.com/Alexpux/MINGW-packages/tree/master/mingw-... We also have static builds and 64bit support for the mingw-w64 target as previously mentioned by jsheard

Sure, I'll make a bug report, should it go here? https://github.com/alexpux/mingw-packages BTW thing that I was able to compile with old MSYS + cmake from cmake.org, but can't with MSYS2 and mingw-w64-i686-cmake is https://github.com/Absolight/pkcs11-proxy

> As far as I can tell, msys2 is still posix/GNU for windows, with alternate shell (bash, not powershell etc) and alternate filesystem (posix/gnu-like)? While mingw is/was gnu/posix binaries for windows The M in MSYS2 stands for Minimal. Meaning the Cygwin-y part is as small as is necessary to run a shell, bash and autotools to configure and build native Windows software that links to msvcrt.dll with no dependency on the Cygwin derived msys-2.0.dll what-so-ever. The software built from the recipes here: https://github.com/Alexpux/MINGW-packages .. does not link to the GPLed msys-2.0.dll. It is built with mingw-w64 GCC. The focus of the project is to expand that collection of software.

It seems we have a libvirt PKGBUILD but no released package. Here is the MSYS2 approach to software development, shamelessly taken from ArchLinux. Could you try this: pacman -Ss base-devel mingw-w64-x86_64-toolchain git clone https://github.com/Alexpux/MINGW-packages.git cd MINGW-packages/mingw-w64-libvirt MINGW_INSTALLS=mingw64 makepkg-mingw -s pacman -U *pkg*xz .. and if it doesn't work file a ticket on: https://github.com/Alexpux/MINGW-packages/issues .. otherwise you should have an MSYS2 libvirt. even if it does work, file a bug asking that mingw-w64-libvert gets packaged. You really should not mix binaries from different ecosystems and compilers. I do not know how TDM configure their compilers or how Fedora configures theirs (exception models, C++ ABIs) but it is a risky business and I caution strongly against it

This has been answered before. No, the msys2 repo doesn't follow the Cygwin packaging versions or schedules at all. They are built from the recipes at: https://github.com/Alexpux/MSYS2-packages .. they link to msys-2.0.dll which is Cygwin derived and are thus GPLed and exist to provide a POSIX-y shell and build tools to allow building: https://github.com/Alexpux/MINGW-packages .. which are full of native Windows software under various licenses.

MSYS2 makes Windows be less of a special case for C/C++ software development. You can use all your favorite build tools from Linux, and there is a large and growing library of software you can install with the package manager. It's easy to contribute your own packages or improve existing ones by making pull requests to here: https://github.com/Alexpux/MINGW-packages

Windows is supported and works, there should be no reason to add new code. The only thing lacking is a recent Windows build. However, it should be easy to build via https://github.com/Alexpux/MINGW-packages .

If you're using MSYS2 to get your MinGW compilers, the package has been updated, but you won't see builds on the mirrors until all the other packages have been rebuilt for GCC 5.1/5.2 (due to the ABI change.) https://github.com/Alexpux/MINGW-packages/commit/a6a16a3

Another ^nix -> Windows package system is the pacman port available in msys2: http://sourceforge.net/projects/msys2/ msys2 has an impressive package list [1] and is almost [2] an amazing solution for mixed-platform projects. [1] https://github.com/Alexpux/MINGW-packages) [2] The one caveat is that it is still susceptible to the Cygwin BLODA problem whereby under certain conditions and software combinations, Windows becomes dangerously unstable after too many calls to fork.

Yes, pacman is wonderful. We're very grateful to the Arch Linux devs. You guys are all correct, we've not paid nearly enough attention to marketing. Here's the description I tried to post: MSYS2 is an updated, modern version of MSYS, both of which are Cygwin (POSIX compatibility layer) forks with the aim of better interoperability with native Windows software. The name is a contraction of Minimal SYStem 2, and aims to provide support to facilitate using the bash shell, Autotools, revision control systems and the like for building native Windows applications using MinGW-w64 toolchains. We wanted a package management system to provide easy installation of packages, and ported Arch Linux's pacman. This brings many powerful features such as dependency resolution and simple complete system upgrades, as well as providing the build system (makep