10 ms·

MSYS2: Arch Linux on Microsoft Windows

203 points by g1n016399 11y ago

analognoise 11y ago
Msys2 is amazing, and everyone should know about and support this project.
- aidenn0 11y ago
  I had never heard of it before this. Does it have updated cygwin libraries? The ones in msys are really old and crufty.
  - lqdc13 11y ago
    It has new libs like new GCC etc. However, it's not nearly as usable as arch. Things like vim configs have differences.
    - striking 11y ago
      You can always update the configuration to better match Arch's and file a pull request against it. Here's the link to the msys2-packages repo for Vim, for example: https://github.com/Alexpux/MSYS2-packages/tree/master/vim https://github.com/Alexpux/MSYS2-packages/tree/master/vim Same build system and everything, it just requires some finagling and copying of the PKGBUILDs.
      - RayDonnelly 11y ago
        Indeed, we really want people attached to or passionate about the projects we provide packages for to jump on board. There's loads of interesting work to do, so please consider rolling your sleeves up.
    - deleted 11y ago
      [deleted]
    - jsmthrowaway 11y ago
      vim configs are often different per-platform anyway. I have an if mac/else block in my gvimrc, since gfn, for example, requires "Font:hSize" on OS X and another type of font selector on Linux-based systems. Things like that are not really new.
  - bjg 11y ago
    Yea, they track it pretty closely. See: https://github.com/Alexpux/Cygwin/tree/msys2-master https://github.com/Alexpux/Cygwin/tree/msys2-master
  - RayDonnelly 11y ago
    Yes, we are very concurrent with Cygwin. We have a modern Github-centric approach to software development and use ArchLinux's Pacman so like them are a rolling software distribution. We hope that other software projects will use us as their library provider and build enviornment on Windows, as that way it should be easier for them to also keep up to date. Unlike the old MSYS, we are also 64-bit and that allows using --enable-auto-image-base which means no more needing to rebase your DLLs. Also, Cygwin have made great strides over the many years since MSYS forked from them and it is now both much faster and more standards compliant. Git-4-Windows is also based on MSYS2 now and some day (hopefully soon) we will fully merge their work (a lot has been merged already) and use their native git executable.
    - 2bitencryption 11y ago
      Sorry for the basic questions, but the github page (and SourceForge page) aren't answering all of my beginner's questions... If Msys2 is Cygwin-derived, does that mean all packages in the Msys2-Pacman are all Cygwin packages? I.e., making this "Cygwin with Pacman as a package manager?" Does this also mean Msys2 packages can never be more current than Cygwin packages (not that this is a bad thing, but as far as I know Python3 in Cygwin is still < 3.5). Is the benefit of Msys2 that some packages could be native windows builds instead of Cygwin-dll reliant packages?
      - RayDonnelly 11y ago
        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 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 https://github.com/Alexpux/MINGW-packages .. which are full of native Windows software under various licenses.
        e12e 11y ago
        Is there some more documentation on how msys2 relates to mingw somewhere? I recently came across msys2 when half-heartedly trying to compile Darktable[1] for windows 10. 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. Both have their place -- but I'd be really happy if something akin to msys2 was available more like mingw -- so I could use the (now finally quite usable) standard windows command line along with (hopefully) MS compilers and have some hope of compiling stuff that uses automake etc. As far as I can figure out, msys2 doesn't (try to) help with that? It's more like a GNU chroot that runs under windows? In which case most/many use-cases might be better served with a vm under VirtualBox/hyper-v[2] and/or a true "native" windows port? Not meant as criticism of the project, I'm just trying to figure out if I've understood the focus of msys2 correctly. Finally, for those wishing for "more GNU" on windows, one of the most pleasant discoveries I've made, is the scoop package manager: http://scoop.sh/ http://scoop.sh/ [1] http://www.darktable.org/install/ http://www.darktable.org/install/ [2] Especially if/when Vagrant works out of the box with hyper-v -- I'm not quite clear on the current status, but looks like it's been enabled and is included in default Vagrant now: https://www.vagrantup.com/docs/hyperv/index.html https://www.vagrantup.com/docs/hyperv/index.html
  - pippy 11y ago
    One thing I do like about msys over cygwin is that compiled binaries don't have a dependency on a dll. If msys2 is using cygwin libraries, does it have the same dependency?
    - aidenn0 11y ago
      You're wrong about that; mingw doesn't require dependency on the dll, msys does.
      - Benjamin_Dobell 11y ago
        Huh? No. Cygwin depends on a DLL. Mingw does not. Msys is just a user-land set of tools.
        rossy 11y ago
        Yep, but those tools rely on a DLL (msys-1.0.dll or msys-2.0.dll,) which is Cygwin by another name. MSYS is not MinGW. Programs like Bash will never run under MinGW because they rely on things like fork(), which are only provided by Unix, Cygwin, or a Cygwin fork like MSYS.
        RayDonnelly 11y ago
        .. ish, there are significant differences. In terms of amount of code, minor, but in terms of behaviour, not so. Mainly, when msys-2.0.dll detects it is calling a native program it translates any arguments that look like paths to Windows form. The same is true for some specific environment variables.
        aidenn0 11y ago
        I thought some of the msys tools relied on a cygwin-like DLL for fork().
anonbanker 11y ago
More GNU software taking over windows is a good thing. Especially when it painlessly handles package management. If I'm ever forced to use a windows machine for work, I'll make sure to install this first.
- RayDonnelly 11y ago
  It's really nice to see the amount of gnome stuff we've got now. And GTK-3 on Windows looks quite pretty I think.
  - aidenn0 11y ago
    I'll have to check gtk3 on windows out. gtk2 was sad looking on windows compared to Qt and Tk
malkia 11y ago
How is fork() implemented?
- RayDonnelly 11y ago
  The same way that Cygwin implements fork (the msys2-runtime is a very light fork of Cygwin): https://www.cygwin.com/faq.html#faq.api.fork https://www.cygwin.com/faq.html#faq.api.fork The packages in the msys2 repository (which, if they link to msys-2.0.dll are all GPL licensed) only really exist to aid building the packages in the mingw32 and mingw64 repositories which don't implement fork() at all and are the real purpose of MSYS2, i.e. providing normal Windows software. If you want a POSIX-y system, please use Cygwin.
- glibgil 11y ago
  midipix has real fork. It's in alpha http://midipix.org/ http://midipix.org/
  - RayDonnelly 11y ago
    midipix is a very interesting project.
  - botw 11y ago
    what is the benefit for midipix comparing with mxe.cc mentioned above?
    - glibgil 11y ago
      real fork is the benefit
- oxide-NL 11y ago
  Hi totally not topic related but i just created a acc just to ask you rather rudely one thing. Could you tell me how the FPS locking works in MGS Integral? I've found a post of you years back about working on the pc port. I've been hacking away the last few days. managed to make it run semi decent on W10 64b & fullscreen But the frames are locked at 24fps ingame (not 30 as you thought to remember in that post) wish you give me some pointers i have allot more questions. I'd appreciate any form of help. my mail// j j r t 1 9 9 0 AT G mail DOT com
kbar13 11y ago
is this actually arch linux or pacman + packages ported to windows? maybe that's the same thing, idk
- RayDonnelly 11y ago
  It's the latter. Arch Linux is Arch Linux.
deleted 11y ago
[deleted]
DavidEGrayson 11y ago
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 https://github.com/Alexpux/MINGW-packages
- srean 11y ago
  Yes it helps a whole lot. For me the big conceptual leap was about dynamic libraries (linking, loading and organizing it in the file system). Windows and Linux does them differently and organize them differently.
  - RayDonnelly 11y ago
    We adopt that. We buck the "Program Files" silliness, and go all-in for FHS layout and shared libraries.
    - srean 11y ago
      If you don't mind, could you elaborate a little. Not that I could do more than thank and upvote in return. In fact consider those done already.
      - RayDonnelly 11y ago
        Ok, I don't know the level of elaboration you are asking for, so apologies if it I go too far. FHS is just the split up at the top level into bin, lib, include, etc, share as opposed to having a folder called, e.g. MyApplication. Some people hate it, but it allows sharing libraries easily. Apple go for something of a hybrid with Frameworks. MSYS2 goes full Linux-style, even for our mingw-w64 (native) softare. "C:\Program Files\MyApplication" is the complete opposite. No sharing. No good for anyone. Usually software is configured so that at `make install` time it will pull the DLLs of its dependencies beside its executables on Windows, so that, for example a Qt-based game would be packaged with the Qt DLLs in the same folder as the executable. On MSYS2 we disable this code-path (ok, build-system code-path) and adopt the Linux path instead, so that our final package contains only the executable and a record to say "I also need the Qt shared libraries package version 5.5-3". In fact, pacman doesn't allow us to make two packages with the same final files in it since it's a System Package Manager and it disallows such conflicts (unless the packages are marked as conflicting). The other common thing you'll see with Windows software is people compiling and linking to static libraries because it's safer than DLL hell. It might be safer in that regard, but it's a security nightmare for the user (though they often can't know it), so we don't do that either. Our library packages do tend to come with static libraries, but our executables link to shared libraries by default which are also provided. This way, when a security issue is found in a library, we don't need to update a load of packages containing executables that linked to that library statically, since none (or very few, some may slip through by mistake) do.
aurora72 11y ago
Cygwin's got some issues about portability, IMHO. When a Cygwin application is run from a shell & terminal emulator other then Cygwin's defaults it throws up an error like: "cygheap base mismatch detected - 0x612F7400/0x612FB400 This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version should reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. Segmentation fault" It's almost like they're coupled to some particular shell and some particularly configured terminal emulator (Mintty). Cygwin is the historical leader of Linux on Windows but that limitation is never desirable. MSYS and MSYS2 don't seem to have such a limitation and that's nice.
- RayDonnelly 11y ago
  IMHO you have managed to get into a situation where Windows has been asked to run two different cygwin1.dlls at the same time and Cygwin has detected this. (I recommend using Process Hacker 2 for helping to track down which processes have handles to cygwin1.dll). This is unfortunately just something you need to manage for yourself. Cygwin got itself into trouble like this because it never had a good enough package management story (because Windows can't overwrite a currently loaded dll, they didn't attempt a good system package manager, as best I understand it) so developers would end up bundling cygwin1.dll alongside their own executables instead, so there would end up being lots of cygwin1.dlls on a users machine. The same thing could happen on MSYS2 if you had two MSYS2 environments, however, to get them both in-sync again, you'd just have to do "update-core" in each and that would be that.
- TickleSteve 11y ago
  MSYS is Cygwin based and so does have the same issue. As has been mentioned, its a DLL management issue, not inherent to the design of CygWin.
wnevets 11y ago
how does this compare to the bash emulation that comes with git for windows? https://git-for-windows.github.io/ https://git-for-windows.github.io/
- barrkel 11y ago
  https://github.com/git-for-windows/git/wiki/Package-management https://github.com/git-for-windows/git/wiki/Package-manageme... Git for Windows uses this project.
  - glandium 11y ago
    ... but doesn't include pacman
    - RayDonnelly 11y ago
      We need to merge our work carefully. Git-4-Windows with pacman and makepkg wouldn't work too well at present, as MSYS2 with a native git wouldn't work too well at present.
      - zodiakzz 11y ago
        Maybe you should mention this on that page then instead of going on and on about pacman when you don't even include it lol
        RayDonnelly 11y ago
        I work on MSYS2, not Git-4-Windows. We come with Pacman included.
        botw 11y ago
        The effort for MSYS2 and Git-4-Windows should be merged as one project.
- 11y ago
kungfooman 11y ago
MSYS2 is really nice, but it fails on bigger projects like compiling Blender.
- RayDonnelly 11y ago
  There was a time (around Blender 2.70) when we did provide Blender packages and it did compile (of course, since all our software is built from source) but then llvm dropped JIT around version 3.5 and it became incompatible with OpenShadingLanguage. We made a choice that we'd rather forge ahead with modern LLVM and Clang (for Rust, Clang-GCC and Julia) than hang back to support Blender. Given our very limited resources, this was still probably the right decision, however, we might have made a choice to create a special llvm35 package at that point, but we had no idea that OpenShadingLanguage would take so long to adapt to MCJIT, which the still haven't done to this day, as far as I know. The important point here is that MSYS2 is a very open-source, limited resources project. We aren't experts in all packages, so if you are knowledgeable about llvm, OpenShadingLanguage and Blender and are interested to do so, then please help out. For Blender, getting CUDA support into MSYS2 is probably high up on the priority list too.
edvinbesic 11y ago
So am I understanding this correctly, but this is not a compatibility layer where we can run native linux applications on windows, instead it's like cygwin where we can run ported applications, only this one uses pacman for distribution of packages?
- cremno 11y ago
  Correct. The title is definitely misleading. The linked website doesn't even mention Arch Linux at all.
- RayDonnelly 11y ago
  Please read the links on the linked to page. MSYS2 is a rolling software distribution providing software built with the mingw-w64 compilers. Some of the software is Cygwin-like, but not much, only enough to distribute (and build) the native (mingw-w64) software and provide a shell.
- stuaxo 11y ago
  Nope, and apart from virtualisaton there isn't a good story for that. There was LINE which was superceded by CoLinux. However the 64 bit port of CoLinux was never completed.
goodplay 11y ago
How are packages authenticated? I did an evaluation a couple of months ago but decided to drop it when I saw that packages where being pulled over plain HTTP and seemingly no authentication was being preformed. For software build systems - my use case - this type of security lapse is a deal breaker.
- aidenn0 11y ago
  I don't know about msys2, but pacman supports gpg signatures, so all they would need to do (and perhaps have done already) would be to configure it for master keys. The initial download that includes the master public keys ought to be done over https, of coures.
  - rossy 11y ago
    Yep. MSYS2 uses pacman's support for GPG signatures. The links to the installers on the website don't use HTTPS, but it looks like they've added checksums of the installers to the website itself, which is served over HTTPS.
- DavidEGrayson 11y ago
  For what it's worth, pacman does support GPG signature verification, HTTPS, and SHA-256 checksums. There is a GitHub user right now making a bunch of pull requests to MSYS2 to make our PKGBUILD scripts more secure, mostly by using HTTPS and SHA-256 whenever possible.
Benjamin_Dobell 11y ago
Yeah, +1 for this project. Using it to compile cross-platform software (Heimdall) on Windows. Saves me maintaining two project files. Pair this with CLion and you've got yourself a complete cross-platform workflow.
aidenn0 11y ago
Is there any way to summon dang to fix a title? This project uses the Arch Linux package manager, but is otherwise completely unrelated to Arch.
- mikekchar 11y ago
  Just because it is a lot of clicks away, here is the introduction in the wiki for MSys2: https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/ https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/ Basically it is mostly POSIX development platform for Window based on cygwin, using the pacman package manager. When I was working on a Windows box oh-so-many-years-ago, I would have loved this. It's too bad that this title is here because I assumed this was running Arch in a container on Windows or some such thing. This is much more useful.
deleted 11y ago
[deleted]
deleted 11y ago
[deleted]
fithisux 11y ago
Msys2 is a fantastic project with a lot of packages. It saved the day when compiling H3D and even Hugin. It is a pitty it cannot build latest Abiword/Gnumeric yet. But we have Cygwin for this. In any case it is a very serious addition to Windows ecosystem and people should start rethinking using Visual Studio which provides no pre-compiled libraries or package management. However, one ca get a descent alternative development environment by using msys2/tdm-x64 and fedora precompiled packages.
- RayDonnelly 11y ago
  I have literally no idea why you would even consider combining MSYS2 with TDM-x64 and Fedora precompiled. Just use MSYS2. It is all that you need. Can you explain why you would do this?
  - fithisux 11y ago
    Because I needed libvirt. I have msys2/mingw64 but for my Golang cgo I have an alternative install tdm-x86_64 + fedora mingw64 x86_64 packages I used msys2 to hand compile pkg-config with these packages. In this respect I have libvirt available to my golang.
    - RayDonnelly 11y ago
      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 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. All your packages should be compiled with the same toolchain. Why would you use TDM compilers anyway? MSYS2 comes with its own: pacman -S mingw-w64-x86_64-toolchain gets you the 64-bit version.
xaduha 11y ago
I tried it recently, didn't work with cmake OOB the way old msys did for me.
- RayDonnelly 11y ago
  pacman -S mingw-w64-{x86_64,i686}-cmake There's you out of the box. You might have tried pacman -S cmake which will have gotten you the msys/cmake package which is used for building the packages in the msys repo (i.e. those linked to msys-2.0.dll). Having to add the mingw-w64-.. prefix is kind of strange, but you get used to it.
  - xaduha 11y ago
    Nope, cmake that was working OOB was installed separately, from https://cmake.org/download https://cmake.org/download I'll try your suggestion and report back.
    - RayDonnelly 11y ago
      Well, we package our own software so we can work around any quirks that our system introduces, but actually generic cmake should work fairly well out of the box. The difference will the down to path translation. We don't stick to the old MSYS rules precisely as that code was re-written for MSYS2. MSYS2_ARG_CONV_EXCL can be used to prevent specific translations from happening too. A bug report would be appreciated anyway.
      - xaduha 11y ago
        Sure, I'll make a bug report, should it go here? https://github.com/alexpux/mingw-packages 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 https://github.com/Absolight/pkcs11-proxy
        RayDonnelly 11y ago
xaduha 11y ago
if you already have Linux or OS X running, but just want to compile some stuff for Windows then I'd recommend looking into http://mxe.cc http://mxe.cc
- botw 11y ago
  What specific stuff does mxe add compared with MinGW cross compiler itself?
  - xaduha 11y ago
    It makes it easies to use MinGW in Linux and OS X, I guess. I wasn't aware that MinGW worked anywhere other than Windows before I heard of MXE.
saghul 11y ago
I love this project. At work we had to make our software run on Windows and MSYS2 makes it feel you're not that far from your confort zone. Maintainers are really helpful when I sent patches and on IRC, and the software has been running stable for over a year now. Rock on folks!
b169118 11y ago
Looks like there are two gcc versions, one is msys/gcc which is 4.9 and the other is mingw gcc which is 5.3. For a person like me who doesn't know anything about the differences between cygwin/mingw/msys etc. this is a little bit confusing.
- botw 11y ago
  As far as I understand, cygwin/msys gcc compiles and links against cygwin.dll/msys.dll which is a incomplete POSIX emulation on Windows. mingw gcc compiles and links against msvc.dll which is MS c runtime for MS win32 native application.
legulere 11y ago
Would be nice to have a small section explaining what MSYS2 is on that page first.
Negative1 11y ago
Can someone give a good rundown what is improved in MSYS2 vs MSYS/MinGW?
- RayDonnelly 11y ago
  It's too much, honestly, but I'm biased.

203 points by g1n016399 11y ago

analognoise 11y ago

Msys2 is amazing, and everyone should know about and support this project.

aidenn0 11y ago
I had never heard of it before this. Does it have updated cygwin libraries? The ones in msys are really old and crufty.
- lqdc13 11y ago
  It has new libs like new GCC etc. However, it's not nearly as usable as arch. Things like vim configs have differences.
  - striking 11y ago
    You can always update the configuration to better match Arch's and file a pull request against it. Here's the link to the msys2-packages repo for Vim, for example: https://github.com/Alexpux/MSYS2-packages/tree/master/vim https://github.com/Alexpux/MSYS2-packages/tree/master/vim Same build system and everything, it just requires some finagling and copying of the PKGBUILDs.
    - RayDonnelly 11y ago
      Indeed, we really want people attached to or passionate about the projects we provide packages for to jump on board. There's loads of interesting work to do, so please consider rolling your sleeves up.
  - deleted 11y ago
    [deleted]
  - jsmthrowaway 11y ago
    vim configs are often different per-platform anyway. I have an if mac/else block in my gvimrc, since gfn, for example, requires "Font:hSize" on OS X and another type of font selector on Linux-based systems. Things like that are not really new.
- bjg 11y ago
  Yea, they track it pretty closely. See: https://github.com/Alexpux/Cygwin/tree/msys2-master https://github.com/Alexpux/Cygwin/tree/msys2-master
- RayDonnelly 11y ago
  Yes, we are very concurrent with Cygwin. We have a modern Github-centric approach to software development and use ArchLinux's Pacman so like them are a rolling software distribution. We hope that other software projects will use us as their library provider and build enviornment on Windows, as that way it should be easier for them to also keep up to date. Unlike the old MSYS, we are also 64-bit and that allows using --enable-auto-image-base which means no more needing to rebase your DLLs. Also, Cygwin have made great strides over the many years since MSYS forked from them and it is now both much faster and more standards compliant. Git-4-Windows is also based on MSYS2 now and some day (hopefully soon) we will fully merge their work (a lot has been merged already) and use their native git executable.
  - 2bitencryption 11y ago
    Sorry for the basic questions, but the github page (and SourceForge page) aren't answering all of my beginner's questions... If Msys2 is Cygwin-derived, does that mean all packages in the Msys2-Pacman are all Cygwin packages? I.e., making this "Cygwin with Pacman as a package manager?" Does this also mean Msys2 packages can never be more current than Cygwin packages (not that this is a bad thing, but as far as I know Python3 in Cygwin is still < 3.5). Is the benefit of Msys2 that some packages could be native windows builds instead of Cygwin-dll reliant packages?
    - RayDonnelly 11y ago
      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 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 https://github.com/Alexpux/MINGW-packages .. which are full of native Windows software under various licenses.
      - e12e 11y ago
        Is there some more documentation on how msys2 relates to mingw somewhere? I recently came across msys2 when half-heartedly trying to compile Darktable[1] for windows 10. 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. Both have their place -- but I'd be really happy if something akin to msys2 was available more like mingw -- so I could use the (now finally quite usable) standard windows command line along with (hopefully) MS compilers and have some hope of compiling stuff that uses automake etc. As far as I can figure out, msys2 doesn't (try to) help with that? It's more like a GNU chroot that runs under windows? In which case most/many use-cases might be better served with a vm under VirtualBox/hyper-v[2] and/or a true "native" windows port? Not meant as criticism of the project, I'm just trying to figure out if I've understood the focus of msys2 correctly. Finally, for those wishing for "more GNU" on windows, one of the most pleasant discoveries I've made, is the scoop package manager: http://scoop.sh/ http://scoop.sh/ [1] http://www.darktable.org/install/ http://www.darktable.org/install/ [2] Especially if/when Vagrant works out of the box with hyper-v -- I'm not quite clear on the current status, but looks like it's been enabled and is included in default Vagrant now: https://www.vagrantup.com/docs/hyperv/index.html https://www.vagrantup.com/docs/hyperv/index.html
- pippy 11y ago
  One thing I do like about msys over cygwin is that compiled binaries don't have a dependency on a dll. If msys2 is using cygwin libraries, does it have the same dependency?
  - aidenn0 11y ago
    You're wrong about that; mingw doesn't require dependency on the dll, msys does.
    - Benjamin_Dobell 11y ago
      Huh? No. Cygwin depends on a DLL. Mingw does not. Msys is just a user-land set of tools.
      - rossy 11y ago
        Yep, but those tools rely on a DLL (msys-1.0.dll or msys-2.0.dll,) which is Cygwin by another name. MSYS is not MinGW. Programs like Bash will never run under MinGW because they rely on things like fork(), which are only provided by Unix, Cygwin, or a Cygwin fork like MSYS.
        RayDonnelly 11y ago
        .. ish, there are significant differences. In terms of amount of code, minor, but in terms of behaviour, not so. Mainly, when msys-2.0.dll detects it is calling a native program it translates any arguments that look like paths to Windows form. The same is true for some specific environment variables.
      - aidenn0 11y ago
        I thought some of the msys tools relied on a cygwin-like DLL for fork().

anonbanker 11y ago

More GNU software taking over windows is a good thing. Especially when it painlessly handles package management. If I'm ever forced to use a windows machine for work, I'll make sure to install this first.

RayDonnelly 11y ago
It's really nice to see the amount of gnome stuff we've got now. And GTK-3 on Windows looks quite pretty I think.
- aidenn0 11y ago
  I'll have to check gtk3 on windows out. gtk2 was sad looking on windows compared to Qt and Tk

malkia 11y ago

How is fork() implemented?

RayDonnelly 11y ago
The same way that Cygwin implements fork (the msys2-runtime is a very light fork of Cygwin): https://www.cygwin.com/faq.html#faq.api.fork https://www.cygwin.com/faq.html#faq.api.fork The packages in the msys2 repository (which, if they link to msys-2.0.dll are all GPL licensed) only really exist to aid building the packages in the mingw32 and mingw64 repositories which don't implement fork() at all and are the real purpose of MSYS2, i.e. providing normal Windows software. If you want a POSIX-y system, please use Cygwin.
glibgil 11y ago
midipix has real fork. It's in alpha http://midipix.org/ http://midipix.org/
- RayDonnelly 11y ago
  midipix is a very interesting project.
- botw 11y ago
  what is the benefit for midipix comparing with mxe.cc mentioned above?
  - glibgil 11y ago
    real fork is the benefit
oxide-NL 11y ago
Hi totally not topic related but i just created a acc just to ask you rather rudely one thing. Could you tell me how the FPS locking works in MGS Integral? I've found a post of you years back about working on the pc port. I've been hacking away the last few days. managed to make it run semi decent on W10 64b & fullscreen But the frames are locked at 24fps ingame (not 30 as you thought to remember in that post) wish you give me some pointers i have allot more questions. I'd appreciate any form of help. my mail// j j r t 1 9 9 0 AT G mail DOT com

kbar13 11y ago

is this actually arch linux or pacman + packages ported to windows? maybe that's the same thing, idk

RayDonnelly 11y ago
It's the latter. Arch Linux is Arch Linux.

deleted 11y ago

[deleted]

DavidEGrayson 11y ago

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 https://github.com/Alexpux/MINGW-packages

srean 11y ago
Yes it helps a whole lot. For me the big conceptual leap was about dynamic libraries (linking, loading and organizing it in the file system). Windows and Linux does them differently and organize them differently.
- RayDonnelly 11y ago
  We adopt that. We buck the "Program Files" silliness, and go all-in for FHS layout and shared libraries.
  - srean 11y ago
    If you don't mind, could you elaborate a little. Not that I could do more than thank and upvote in return. In fact consider those done already.
    - RayDonnelly 11y ago
      Ok, I don't know the level of elaboration you are asking for, so apologies if it I go too far. FHS is just the split up at the top level into bin, lib, include, etc, share as opposed to having a folder called, e.g. MyApplication. Some people hate it, but it allows sharing libraries easily. Apple go for something of a hybrid with Frameworks. MSYS2 goes full Linux-style, even for our mingw-w64 (native) softare. "C:\Program Files\MyApplication" is the complete opposite. No sharing. No good for anyone. Usually software is configured so that at `make install` time it will pull the DLLs of its dependencies beside its executables on Windows, so that, for example a Qt-based game would be packaged with the Qt DLLs in the same folder as the executable. On MSYS2 we disable this code-path (ok, build-system code-path) and adopt the Linux path instead, so that our final package contains only the executable and a record to say "I also need the Qt shared libraries package version 5.5-3". In fact, pacman doesn't allow us to make two packages with the same final files in it since it's a System Package Manager and it disallows such conflicts (unless the packages are marked as conflicting). The other common thing you'll see with Windows software is people compiling and linking to static libraries because it's safer than DLL hell. It might be safer in that regard, but it's a security nightmare for the user (though they often can't know it), so we don't do that either. Our library packages do tend to come with static libraries, but our executables link to shared libraries by default which are also provided. This way, when a security issue is found in a library, we don't need to update a load of packages containing executables that linked to that library statically, since none (or very few, some may slip through by mistake) do.

aurora72 11y ago

Cygwin's got some issues about portability, IMHO. When a Cygwin application is run from a shell & terminal emulator other then Cygwin's defaults it throws up an error like: "cygheap base mismatch detected - 0x612F7400/0x612FB400 This problem is probably due to using incompatible versions of the cygwin DLL. Search for cygwin1.dll using the Windows Start->Find/Search facility and delete all but the most recent version. The most recent version should reside in x:\cygwin\bin, where 'x' is the drive on which you have installed the cygwin distribution. Rebooting is also suggested if you are unable to find another cygwin DLL. Segmentation fault" It's almost like they're coupled to some particular shell and some particularly configured terminal emulator (Mintty). Cygwin is the historical leader of Linux on Windows but that limitation is never desirable. MSYS and MSYS2 don't seem to have such a limitation and that's nice.

RayDonnelly 11y ago
IMHO you have managed to get into a situation where Windows has been asked to run two different cygwin1.dlls at the same time and Cygwin has detected this. (I recommend using Process Hacker 2 for helping to track down which processes have handles to cygwin1.dll). This is unfortunately just something you need to manage for yourself. Cygwin got itself into trouble like this because it never had a good enough package management story (because Windows can't overwrite a currently loaded dll, they didn't attempt a good system package manager, as best I understand it) so developers would end up bundling cygwin1.dll alongside their own executables instead, so there would end up being lots of cygwin1.dlls on a users machine. The same thing could happen on MSYS2 if you had two MSYS2 environments, however, to get them both in-sync again, you'd just have to do "update-core" in each and that would be that.
TickleSteve 11y ago
MSYS is Cygwin based and so does have the same issue. As has been mentioned, its a DLL management issue, not inherent to the design of CygWin.

wnevets 11y ago

how does this compare to the bash emulation that comes with git for windows? https://git-for-windows.github.io/ https://git-for-windows.github.io/

barrkel 11y ago
https://github.com/git-for-windows/git/wiki/Package-management https://github.com/git-for-windows/git/wiki/Package-manageme... Git for Windows uses this project.
- glandium 11y ago
  ... but doesn't include pacman
  - RayDonnelly 11y ago
    We need to merge our work carefully. Git-4-Windows with pacman and makepkg wouldn't work too well at present, as MSYS2 with a native git wouldn't work too well at present.
    - zodiakzz 11y ago
      Maybe you should mention this on that page then instead of going on and on about pacman when you don't even include it lol
      - RayDonnelly 11y ago
        I work on MSYS2, not Git-4-Windows. We come with Pacman included.
        botw 11y ago
        The effort for MSYS2 and Git-4-Windows should be merged as one project.
11y ago

kungfooman 11y ago

MSYS2 is really nice, but it fails on bigger projects like compiling Blender.

RayDonnelly 11y ago
There was a time (around Blender 2.70) when we did provide Blender packages and it did compile (of course, since all our software is built from source) but then llvm dropped JIT around version 3.5 and it became incompatible with OpenShadingLanguage. We made a choice that we'd rather forge ahead with modern LLVM and Clang (for Rust, Clang-GCC and Julia) than hang back to support Blender. Given our very limited resources, this was still probably the right decision, however, we might have made a choice to create a special llvm35 package at that point, but we had no idea that OpenShadingLanguage would take so long to adapt to MCJIT, which the still haven't done to this day, as far as I know. The important point here is that MSYS2 is a very open-source, limited resources project. We aren't experts in all packages, so if you are knowledgeable about llvm, OpenShadingLanguage and Blender and are interested to do so, then please help out. For Blender, getting CUDA support into MSYS2 is probably high up on the priority list too.

edvinbesic 11y ago

So am I understanding this correctly, but this is not a compatibility layer where we can run native linux applications on windows, instead it's like cygwin where we can run ported applications, only this one uses pacman for distribution of packages?

cremno 11y ago
Correct. The title is definitely misleading. The linked website doesn't even mention Arch Linux at all.
RayDonnelly 11y ago
Please read the links on the linked to page. MSYS2 is a rolling software distribution providing software built with the mingw-w64 compilers. Some of the software is Cygwin-like, but not much, only enough to distribute (and build) the native (mingw-w64) software and provide a shell.
stuaxo 11y ago
Nope, and apart from virtualisaton there isn't a good story for that. There was LINE which was superceded by CoLinux. However the 64 bit port of CoLinux was never completed.

goodplay 11y ago

How are packages authenticated? I did an evaluation a couple of months ago but decided to drop it when I saw that packages where being pulled over plain HTTP and seemingly no authentication was being preformed. For software build systems - my use case - this type of security lapse is a deal breaker.

aidenn0 11y ago
I don't know about msys2, but pacman supports gpg signatures, so all they would need to do (and perhaps have done already) would be to configure it for master keys. The initial download that includes the master public keys ought to be done over https, of coures.
- rossy 11y ago
  Yep. MSYS2 uses pacman's support for GPG signatures. The links to the installers on the website don't use HTTPS, but it looks like they've added checksums of the installers to the website itself, which is served over HTTPS.
DavidEGrayson 11y ago
For what it's worth, pacman does support GPG signature verification, HTTPS, and SHA-256 checksums. There is a GitHub user right now making a bunch of pull requests to MSYS2 to make our PKGBUILD scripts more secure, mostly by using HTTPS and SHA-256 whenever possible.

Benjamin_Dobell 11y ago

Yeah, +1 for this project. Using it to compile cross-platform software (Heimdall) on Windows. Saves me maintaining two project files. Pair this with CLion and you've got yourself a complete cross-platform workflow.

aidenn0 11y ago

Is there any way to summon dang to fix a title? This project uses the Arch Linux package manager, but is otherwise completely unrelated to Arch.

mikekchar 11y ago
Just because it is a lot of clicks away, here is the introduction in the wiki for MSys2: https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/ https://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/ Basically it is mostly POSIX development platform for Window based on cygwin, using the pacman package manager. When I was working on a Windows box oh-so-many-years-ago, I would have loved this. It's too bad that this title is here because I assumed this was running Arch in a container on Windows or some such thing. This is much more useful.

deleted 11y ago

[deleted]

deleted 11y ago

[deleted]

fithisux 11y ago

Msys2 is a fantastic project with a lot of packages. It saved the day when compiling H3D and even Hugin. It is a pitty it cannot build latest Abiword/Gnumeric yet. But we have Cygwin for this. In any case it is a very serious addition to Windows ecosystem and people should start rethinking using Visual Studio which provides no pre-compiled libraries or package management. However, one ca get a descent alternative development environment by using msys2/tdm-x64 and fedora precompiled packages.

RayDonnelly 11y ago
I have literally no idea why you would even consider combining MSYS2 with TDM-x64 and Fedora precompiled. Just use MSYS2. It is all that you need. Can you explain why you would do this?
- fithisux 11y ago
  Because I needed libvirt. I have msys2/mingw64 but for my Golang cgo I have an alternative install tdm-x86_64 + fedora mingw64 x86_64 packages I used msys2 to hand compile pkg-config with these packages. In this respect I have libvirt available to my golang.
  - RayDonnelly 11y ago
    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 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. All your packages should be compiled with the same toolchain. Why would you use TDM compilers anyway? MSYS2 comes with its own: pacman -S mingw-w64-x86_64-toolchain gets you the 64-bit version.

xaduha 11y ago

I tried it recently, didn't work with cmake OOB the way old msys did for me.

RayDonnelly 11y ago
pacman -S mingw-w64-{x86_64,i686}-cmake There's you out of the box. You might have tried pacman -S cmake which will have gotten you the msys/cmake package which is used for building the packages in the msys repo (i.e. those linked to msys-2.0.dll). Having to add the mingw-w64-.. prefix is kind of strange, but you get used to it.
- xaduha 11y ago
  Nope, cmake that was working OOB was installed separately, from https://cmake.org/download https://cmake.org/download I'll try your suggestion and report back.
  - RayDonnelly 11y ago
    Well, we package our own software so we can work around any quirks that our system introduces, but actually generic cmake should work fairly well out of the box. The difference will the down to path translation. We don't stick to the old MSYS rules precisely as that code was re-written for MSYS2. MSYS2_ARG_CONV_EXCL can be used to prevent specific translations from happening too. A bug report would be appreciated anyway.
    - xaduha 11y ago
      Sure, I'll make a bug report, should it go here? https://github.com/alexpux/mingw-packages 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 https://github.com/Absolight/pkcs11-proxy
      - RayDonnelly 11y ago

xaduha 11y ago

if you already have Linux or OS X running, but just want to compile some stuff for Windows then I'd recommend looking into http://mxe.cc http://mxe.cc

botw 11y ago
What specific stuff does mxe add compared with MinGW cross compiler itself?
- xaduha 11y ago
  It makes it easies to use MinGW in Linux and OS X, I guess. I wasn't aware that MinGW worked anywhere other than Windows before I heard of MXE.

saghul 11y ago

I love this project. At work we had to make our software run on Windows and MSYS2 makes it feel you're not that far from your confort zone. Maintainers are really helpful when I sent patches and on IRC, and the software has been running stable for over a year now. Rock on folks!

b169118 11y ago

Looks like there are two gcc versions, one is msys/gcc which is 4.9 and the other is mingw gcc which is 5.3. For a person like me who doesn't know anything about the differences between cygwin/mingw/msys etc. this is a little bit confusing.

botw 11y ago
As far as I understand, cygwin/msys gcc compiles and links against cygwin.dll/msys.dll which is a incomplete POSIX emulation on Windows. mingw gcc compiles and links against msvc.dll which is MS c runtime for MS win32 native application.

legulere 11y ago

Would be nice to have a small section explaining what MSYS2 is on that page first.

Negative1 11y ago

Can someone give a good rundown what is improved in MSYS2 vs MSYS/MinGW?

RayDonnelly 11y ago
It's too much, honestly, but I'm biased.