MSYS vs. MinGW: internal environment variables

Question

MSYS2 default shell (bash) can be started choosing among three launchers, which also set the environment variable MSYSTEM. Specifically:

1. msys2_shell.bat sets it to MSYS
2. mingw64_shell.bat sets it to MINGW64 and
3. mingw32_shell.bat sets it to MINGW32.

Apart from the shells' prompt, the visible differences are:

• There is an equivalent shell variable $MSYSTEM exported;
• uname output is based on $MSYSTEM;
• When $MSYSTEM is MINGW*, /mingw*/bin is the first path in $PATH.

Assuming we have /usr/bin/gcc, /mingw64/bin/gcc, /mingw32/bin/gcc, a sensible consequence of the set value of $MSYSTEM is that we will use a different compiler generating a different binary (POSIX or native 32/64).

• What are other significant differences determined by $MSYSTEM value?
• Are there any binaries that make a specific use of this variable?
• Is pacman affected by the subsystem?

Answer 1

The following is extracted from a post by Ray Donnelly, a MinGW-w64 contributor. It enlightens on the subject and is essential preamble to my question.

There are 3 systems, MSYS2 and 32-bit and 64-bit Native Windows systems. Each system has its own repository of software packages in the MSYS2 distribution. [...] that is an important distinction between them. MSYS2 implements a POSIX-y FHS filesystem namespace and that's very important for lots of things.
[...] The MinGW-w64 32-bit and 64-bit systems are Native Windows software which are rooted at /mingw32 and /mingw64 respectively. It's not like we replaced every Linux API call ourselves; most of the upstream projects do this work for us since they already provide Windows ports, but yes sometimes we have to do it. We also add special relocation patches to a lot of the software so that you are free to install the root the whole thing (e.g. C:\msys64) wherever you want. MSYS2 software doesn't need these patches (since the Native Windows location is a hidden installation detail) but MinGW-w64 software often does.
[F]rom an end user perspective, there's only 2 systems, MSYS2 and the XX-bit Native Windows one, and yes, some packages exist for both those systems. Specifically, MSYS2 exists to run development tools necessary to build Native Windows software, so if a build system needs an MSYS2 version of Python or Perl to operate correctly (because it assumes FHS or whatever) then we need to provide those packages. We never add MSYS2 packages without making sure there is a need for them. If you don't know that you need the MSYS2 version of something, then install the appropriate Native Windows one instead.
An example of when you will need MSYS2 Python is if you try to use Google's repo tools. This is because repo uses the fcntl Python module and that module only exists on POSIX-y systems. IMHO Python is doing a bad job of abstracting the OSes here and that's a fundamental thing that a scripting language should do, and fcntl (and pyWin32) should not exist, but I'm not the boss of Python.
Fortunately, Pacman has dependency management and will install the stuff needed for whatever packages you are actually interested in.
GNU Autotools will never work well except via a FHS compliant system with a POSIX shell, and this naturally leads to other tools needing to exist in the same filesystem namespace, such as make, perl, m4, bison, flex etc etc.

Given Ray Donnelly post, what makes up a system is first and foremost the PATH variable, because, depending on directory priorities Google's repo tools will be built with MSYS2 or MinGW packages. In fact the shell script, which switches between MSYS2 and MinGW shells, exports the environment variable MSYSTEM with its argument mingw32|mingw64|msys and sources /etc/profile. The latter, in turn, sets the PATH based on the value of MSYSTEM. By and large for MSYS2 the PATH is /usr/local/bin:/usr/bin:/bin, while for MinGW 64 it is /mingw64/bin:/usr/local/bin:/usr/bin:/bin, therefore running the gcc compilers will execute MSYS2 or MinGW version accordingly. There are other minor env. variables too, for example MANPATH to read the proper manuals, once the proper binaries are called, or PKG_CONFIG_PATH to read the proper lib files, when building.

As regards, pacman it is not totally true that it is not affected, as from @David Grayson comment. MSYS2 wiki vaguely affirms that:

Use msys2 shell for running pacman, makepkg, makepkg-mingw and for building POSIX-dependent software that you don't intend to distribute. Use mingw shells for building native software and other tasks.

Ray Donnelly clarifies the things again in another post :

Generally speaking, you can use any shell for pacman, but you could run into some issues using mingw shells where depending on what packages you've installed into /mingw32 or /mingw64, the post install scripts of packages (which are arbitrary bash scripts) may end up running an unexpected mingw-w64 variant of a program. A concrete example of that would be 'sed'. So running pacman from msys2_shell.bat avoids a class of potential problems (though we'd try to fix any that are reported anyway).

Summing up:

What are other significant differences determined by $MSYSTEM value?
The immediate significant differences are in the related values of the path variables identified by @David Grayson.

Are there any binaries that make a specific use of this variable?
It seems safe to say that there is no specific binary reading directly $MSYSTEM, but a great deal of software use/read the path variables above based on $MSYSTEM.

Is pacman affected by the subsystem?
Yes.

Answer 2

The intention behind the three choices was to give you the option of two different development environments:

1. MinGW: intended for development of native Windows applications. This is further divided into:

   • Mingw32 for producing 32 bit executables, and of course
   • Mingw64 for producing 64 bit executables

   Think of this as where you will do your end-user development. Software that won't normally be run inside of the MSYS2 environment itself.

2. MSYS: intended to build applications that will operate in a posix-y environment with FHS style filesystem naming. Think of this as where you will do development for the tools that are actually running inside Msys2. Or, you can think of this like you would Cygwin.

You can get more information on this subject in this thread on the MSYS2 sourceforge forum.