3 ms·

Thanks for mentioning this. I just started using Windows at home after a long break and defaulted to setting up Cygwin with cmder. Before that I used Arch Linux

• mappu 11y ago
  MSYS2 is a fork of Cygwin. The goal is to make it easier to compile software targeting Windows. Some notable changes are: - It has its own package repository, using PKGBUILDs on github. It can also be updated from within its own shell. Cygwin doesn't do this, for very important reasons, involving autorebase hell which MSYS2 is certainly still subject to. - In their fork of cygwin1.dll, they removed support for symlinks (i.e. `ln -s` creates a full tree copy); and the /cygdrive/ root directory was replaced with / (just like the old/deprecated MSYS1). - It has three startup links, in which gcc/ld/make and the like are all "symlinked" to different versions (e.g. targeting win32, targeting win64, or targeting MSYS2 itself). It makes it easier to compile software targeting windows. You should install separate -devel packages for each "environment". - MSYS2 focuses on packaging dependencies that would be useful for compiling software targeting the Windows platform (e.g. libXYZ). In comparison, Cygwin is more of a mini-OS, packaging applications for general use (e.g. rsync, BIND, MySQL and X11). There is a lot of overlap, but many exclusive packages. - MSYS2 is amenable to merging back with Cygwin, but, the patches they've made to cygwin1.dll can't be upstreamed. Cygwin proposed a new plugin system that would allow MSYS2 functionality within Cygwin, but, nobody has done the work to port MSYS2 to this new system. (maybe outdated information)
  • mappu 11y ago
    One more important note about compiling software with MSYS2 is that the msys2 version of cygwin1.dll (i forget how it's renamed) obviously inherits the same license as cygwin1.dll. Cygwin1.dll is not LGPL. It is GPL. So any program you release compiled with MSYS2 inherits GPL virality, unless you pay Red Hat for a commercial Cygwin license.
    • realharo 11y ago
      By default the gcc packages in the mingw-w64-... groups don't link against that library. You can explicitly include it if you need the POSIX compatibility parts missing from Windows, but most software doesn't.
    • RayDonnelly 11y ago
      This sounds like you're trying to scare people off using MSYS2 altogether with the GPL bogey man, and it misrepresents the point of MSYS2. The 'msys2' software repository (as opposed to the 'mingw32' and 'mingw64' ones) contains things that link to msys-2.0.dll which is GPL, and yes it includes compilers and linkers that in turn generate new PECOFF objects that in turn link to msys-2.0.dll. This repository exists mostly as build scaffolding (Autotools, bash) to support building native Windows software (as exists in the other two repositories) and that is the real goal of MSYS2. If you want POSIX-y GPLed software on Windows, use Cygwin. You are right to caution people on the naive usage of our msys2/gcc package, but you've made it sound like something much worse than it is.
  • RayDonnelly 11y ago
    Autorebase hell is I hope a thing of the past. We made all of the executables involved in the running of pacman static (except msys-2.0.dll obviously, and some post-install scripts, but we try to remove those) and split the update procedure into two parts, "update-core" which handles updating the core of MSYS2 and pacman. The rest of the system update is then completed with "pacman -Su". We've had no reports of update failures since then. We didn't remove support for symlinks, you can enable them in the MSYS env. var winsymlinks:nativestrict if you want. If symlinks didn't require special permissions, we'd enable them by default, but unfortunately they do. Maybe one day Microsoft will change their minds on this. I can only hope so. I guess you may have meant that we don't create the 'Cygwin special' symlinks that winsymlinks:native falls back to when it doesn't get permissions? Yes those are an interoperability disaster for MSYS2 when native programs read them.