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:
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.
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.
I don't know why my sibling comment is dead, but windows is the only non POSIX and UNIX-like still relevant. May be there is a niche non-UNIX OS that I don't know about?
OS X is POSIX certified, and Linux and BSD are obviously UNIX-like and mostly compliant.
Apart from the precise meaning of POSIX, windows is the only OS in widespread use not part of the UNIX-like family.
There are the embedded and mainframe OSes, but I guess they might be considered niche.
Not so niche are iOS and Android, which aren't fully POSIX compliant.
Then being POSIX compliant is only half of the story, because each OS tends to be certified to specific versions and there is room for implementation specific behaviours.
For example, Aix used to have Windows like model for dynamic libraries. OS X and its derivatives have Frameworks and so on.
Finally POSIX only applications are constrained to CLI and daemons only, as everything else falls outside POSIX.
> Finally POSIX only applications are constrained to CLI and daemons only, as everything else falls outside POSIX.
That is not a small group, especially as it includes your build environment. In Windows, many times I had a problem that I cannot run ./configure (or worse: the package used a home grown build system that assumed unix-y environment; py2cairo, I'm looking at you), not only because of bash/sed/m4/awk/etc, but also not counting with cl.exe (VS compiler).
Side note: OSX has not only frameworks, but also dylibs. You can treat existing framework as dylib, it will link fine.
> That is not a small group, especially as it includes your build environment.
Assuming the build environment is about CLI and daemons as I mentioned.
Anything else isn't guaranteed to work. To pick on your example, Cairo needs more than just POSIX to compile. X11 isn't part of POSIX.
Have you experience with big UNIXes like Aix, Solaris, HP-UX, Tru64 and DG-UX?
It been awhile since I used most of them (1994 - 2006), but I clearly remember surprises with those scripts (autotools and friends) when running them outside GNU/Linux.
Maybe the situation has improved there, since like many of us, my UNIX like experience is nowadays constrained to GNU/Linux distributions and Mac OS X.
Build environment usually is about CLI. Without daemons, abstracting from distcc and similar tools.
X11 for Cairo is optional. As is OpenGL or Win32 GDI. But yes, POSIX as it is, is a very limited API and for practical purposes, you need other APIs.
Yes, I have past experience with DX-UG/Tru64 and Solaris. At the time when Alpha AXP was a current chip, it was a little wonder to get to compile the same source code with different compilers, as they had different ideas about what a valid C code is. For Solaris, the easiest way to build anything was to get gcc instead of sun studio compiler. I think that Sun's GNU packages were built using gcc too.
Nowadays, I don't know about all other unices, because I'm using only Linux and OSX too. From the commonly used OSes, the most annoying to build something on is Windows.
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.
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.
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?
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:
[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
> 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.
Ok, thank you for the reply. Is there some more documentation on building "complicated" packages somewhere?
Eg. for darktable, one needs libgtk+ and intltool -- as well as a xslt library -- perhaps there's a quick way to leverage what's already done for Arch[1] when attempting to build on windows?
Note, I'm not necessarily expecting such a build to work perfectly -- but if one could at least get to the point where any build-failures where in the darktable source, not from missing essential dependencies -- that'd be a start :-)
> The software built from the recipes here: (...)
So, if I understand correctly, one installs msys2 from the exe-installer, then updates the system with pacman -- and installs packages one wants from the ones in mingw-packages... and then those packages/binaries should/can be added to the normal windows path?
And that last bit one has to do manually? (Lets say I just want grep.exe and sed.exe in my path for example)?
The documentation (once you've read about pacman, and makepkg on the wiki or on Arch Linux's wiki) is in the PKGBUILD files. Building all packages should be done with the exact same command, so there's not really any different documentation for "complicated" packages. Just emit:
makepkg-mingw -s (*)
.. the complication is in the recipes and patches (which hopefully end up being upstreamed, but not often enough).
Darktable won't work without a good amount of effort as AFAICT, no one's built it for Windows. We have most of the dependencies though.
You'd install MSYS2, then pacman -S base-devel and mingw-w64-{x86_64,i686}-toolchain, then not install anything else (*). The -s here means "sync dependencies", sync is pacman speak for install, more or less. By setting up the dependencies in the PKGBUILD correctly, and adding -s to the makepkg-mingw command, you guarantee that you've got it correct for when people install the binaries when it gets to that stage, and that the CI systems fetch the right dependencies when they try to build darktable.
Don't add anything to your Windows PATH. Ever. Why would you break other software by having it run MSYS2 software by mistake? I've never understood software that presumes to add itself to the Windows PATH. Particularly without asking. Really, just what? We don't even ask. When you run our shells we add you to the PATH during that session.
Anyway, that's my global Windows PATH rant over.
I guess that's the bit you didn't get. To use MSYS2, don't use cmd.exe or powershell. Instead, run msys2_shell.bat (to use makepkg_mingw or makepkg), mingw64_shell.bat or mingw32_shell.bat, accept the ways of and use the mintty terminal.
Next you would convert the following PKGBUILD from Arch Linux:
.. to MSYS2/mingw-w64 form (look at the roughly 1000 references in MINGW-packages), use pacman -Ss to find the equivalent package name, use makepkg-mingw -s to test.
If I'm understanding it right, this is fantastic! I'm very happy using pacman and AUR with Arch, and having analogous resources for MSYS opens up a whole world of possibilities for running good software on Windows.
Right. Then I think I had the right idea (of what MSYS2 is/aims to be). I was sort of hoping it was less self-contained - and more integrated with the windows-side.
I hope you misunderstand slightly still. So msys2 executables - those linked to msys-2.0.dll can be run from Windows executables (or double clicked to launch from Windows Explorer, or pinned to the Start Menu or the Task Bar), for example, you can tell TortoiseGit to use MSYS2's git.exe and it'll work quite well, or Qt Creator to use msys2's msys-2.0.dll linked gdb.exe (as opposed to our mingw-w64-{x86_64,i686}-gdbs that are not). I went to some lengths to make that stuff work correctly. The same applies to MSYS2's mingw-w64 executables.
Both types of executable can also be run from from PowerShell or cmd.exe too of course. In very few cases you may need to add the correct "bin" folder to your PATH before you do so.
If you want to build MSYS2 packages using the build system we've adopted, then you need to use our shell. That is all (and a reasonable requirement).
You can't link (at the C/C++ level) msvcrt.dll linked-executables with Visual Studio > 6.0 executables / libraries and expect things to work properly for anything but the most trivial cases.
These aren't things that MSYS2 imposed though, these are just the realities of inter-operation between GCC and MSVC as they stand at present.
Thanks for answering! I'll have to check it out. Fortunately I don't spend much time on windows these days, and I had switched to babun from msys because of so many deficiencies in their old cygwin fork.
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?
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.
.. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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
Yeah, but you need to be clear that it wasn't our cmake build of course.
Generally get used using, asking for and contributing to MSYS2 packages if you can. That way everyone benefits. It's not the norm on Windows, but it very much should be.
But isn't that just Bash and a few other tools here and there ?
This is a more complete suit of tools that intends to be sufficient for building any Gnu/Linux/Posix software on a Windows platform. A much more ambitious goal.
Git-4-Windows is a great project, just with a different focus. They contribute a lot to our packages (and Cygwin) too since git (and the shell) drags in quite a lot of stuff.
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.
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.
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
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.
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
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:
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.
https://github.com/Alexpux/MINGW-packages