
MSYS2: Arch Linux on Microsoft Windows - g1n016399
https://msys2.github.io/
======
DavidEGrayson
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)

~~~
pjmlp
You could say the same about any other OS that isn't GNU/Linux.

Windows isn't the only one non POSIX and even POSIX ones do have substantial
differences.

~~~
ikurei
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.

~~~
pjmlp
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.

~~~
vetinari
> 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.

~~~
pjmlp
> 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.

~~~
vetinari
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.

------
aidenn0
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
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.

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

~~~
aidenn0
I had never heard of it before this. Does it have updated cygwin libraries?
The ones in msys are really old and crufty.

~~~
lqdc13
It has new libs like new GCC etc. However, it's not nearly as usable as arch.
Things like vim configs have differences.

~~~
striking
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
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.

------
goodplay
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
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
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.

------
aurora72
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
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.

------
edvinbesic
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
Correct. The title is definitely misleading. The linked website doesn't even
mention Arch Linux at all.

------
Benjamin_Dobell
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.

------
xaduha
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
What specific stuff does mxe add compared with MinGW cross compiler itself?

~~~
xaduha
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.

------
b169118
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
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.

------
saghul
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!

------
kbar13
is this actually arch linux or pacman + packages ported to windows?

maybe that's the same thing, idk

~~~
RayDonnelly
It's the latter. Arch Linux is Arch Linux.

------
anonbanker
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
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
I'll have to check gtk3 on windows out. gtk2 was sad looking on windows
compared to Qt and Tk

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

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

~~~
RayDonnelly
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
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
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
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
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.

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

~~~
RayDonnelly
It's too much, honestly, but I'm biased.

------
wnevets
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/)

~~~
srean
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.

~~~
RayDonnelly
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.

------
malkia
How is fork() implemented?

~~~
glibgil
midipix has real fork. It's in alpha
[http://midipix.org/](http://midipix.org/)

~~~
botw
what is the benefit for midipix comparing with mxe.cc mentioned above?

~~~
glibgil
real fork is the benefit

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

~~~
RayDonnelly
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.

------
fithisux
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
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
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
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.

~~~
fithisux
I keep the ecosystems tightly separated. I will try later today and inform
you.

