Will you please answer some questions about the topic?
First, as i've understood it is possible to install software for any of these "namespaces" using appropriate %.bat: MSYS2, MINGW32 and MINGW64. First is fork of Cygwin, and so many of it functionality are not called from Windows DLLs and API, but virtualized via msys###.dll, and because of this layer MSYS2 software can be slower than native ones. MINGWxx are direct ports of Linux software to Windows, and replace every incompatible Linux API function with the same from Windows. Right?
For some software i've searched pacman shows versions for all 3 "namespaces". And seems i can install all of 32- and 64-bit MINGW version and %your_MSYS2_bit% MSYS2 version. I don't know why would anyone install 3 versions, but now i myself have some packets both for MINGW and MSYS. For example, i've installed the only available MINGW version of Clang, and it automatically installed MINGW gcc.
The main question is here: do i have to start different shells to run software for different subsystems? As for now i can't run clang from MSYS2 shell, only from MINGW. Is it possibly to use on shell for soft from any subsystem?
Is it safe to have parallel jobs in different shells? Do they share any data?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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. I'll get onto namespaces later, but yes, that is an important distinction between them. MSYS2 implements a POSIX-y FHS filesystem namespace and that's very important for lots of things.
You are right that MSYS2 is a Cygwin derivative (with patches to improve inter-operation with Native Windows software) and so many operations are slower due to its POSIX translation layer.
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.
There's no good reason I can think of for an end user to install both 32 and 64-bit Native Windows software on their machine. If you've got a 64-bit machine, then you shouldn't bother installing 32-bit software on it, and if you've got a 32-bit machine, then plainly, 64-bit software will not even run on it. People who contribute to MSYS2 however, need to check that the packages they are changing can be built and run on both systems.
So, with that said, from 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.
Thank you very much for the answer. Things are getting clearer.
Of course i've read https://sourceforge.net/p/msys2/wiki/Home/ but seems these questions are not described here.
So: MSYS2 environment is mainly for building software for MINGW64 environment and for software requiring FHS, right?
And MINGW64 is thought to be main working system? Then why on the "Installing..." wiki page there is only msys2_shell.bat mentioned, and no MINGW?
One more thing to add to the absent "troubleshooting" section: always check the location of the executable you are calling in case of unusual troubles. "which %your_command%" can save you much time.
"which" command says MINGW will use MSYS version of the executable if there is no MINGW version installed, and vice versa. This is major info, i think.
And all subsystems use the same home directory.
I've also made some performance benchmarks. They are silly, but anyway.
Hi.
Will you please answer some questions about the topic?
First, as i've understood it is possible to install software for any of these "namespaces" using appropriate %.bat: MSYS2, MINGW32 and MINGW64. First is fork of Cygwin, and so many of it functionality are not called from Windows DLLs and API, but virtualized via msys###.dll, and because of this layer MSYS2 software can be slower than native ones. MINGWxx are direct ports of Linux software to Windows, and replace every incompatible Linux API function with the same from Windows. Right?
For some software i've searched pacman shows versions for all 3 "namespaces". And seems i can install all of 32- and 64-bit MINGW version and %your_MSYS2_bit% MSYS2 version. I don't know why would anyone install 3 versions, but now i myself have some packets both for MINGW and MSYS. For example, i've installed the only available MINGW version of Clang, and it automatically installed MINGW gcc.
The main question is here: do i have to start different shells to run software for different subsystems? As for now i can't run clang from MSYS2 shell, only from MINGW. Is it possibly to use on shell for soft from any subsystem?
Is it safe to have parallel jobs in different shells? Do they share any data?
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. I'll get onto namespaces later, but yes, that is an important distinction between them. MSYS2 implements a POSIX-y FHS filesystem namespace and that's very important for lots of things.
You are right that MSYS2 is a Cygwin derivative (with patches to improve inter-operation with Native Windows software) and so many operations are slower due to its POSIX translation layer.
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.
There's no good reason I can think of for an end user to install both 32 and 64-bit Native Windows software on their machine. If you've got a 64-bit machine, then you shouldn't bother installing 32-bit software on it, and if you've got a 32-bit machine, then plainly, 64-bit software will not even run on it. People who contribute to MSYS2 however, need to check that the packages they are changing can be built and run on both systems.
So, with that said, from 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.
Does this clear things up any?
Please read https://sourceforge.net/p/msys2/wiki/Home/ for more information.
Thank you very much for the answer. Things are getting clearer.
Of course i've read https://sourceforge.net/p/msys2/wiki/Home/ but seems these questions are not described here.
So: MSYS2 environment is mainly for building software for MINGW64 environment and for software requiring FHS, right?
And MINGW64 is thought to be main working system? Then why on the "Installing..." wiki page there is only msys2_shell.bat mentioned, and no MINGW?
One more thing to add to the absent "troubleshooting" section: always check the location of the executable you are calling in case of unusual troubles. "which %your_command%" can save you much time.
"which" command says MINGW will use MSYS version of the executable if there is no MINGW version installed, and vice versa. This is major info, i think.
And all subsystems use the same home directory.
I've also made some performance benchmarks. They are silly, but anyway.
Testing bzip2 unpacking time:
timer64 C:\msys64\usr\bin\bzip2.exe -t C:\mono-3.4.0.tar.bz2
Commit = 9932 KB = 10 MB
Work Set = 8380 KB = 9 MB
Kernel Time = 0.109 = 0%
User Time = 43.352 = 97%
Process Time = 43.461 = 97%
Global Time = 44.540 = 100%
timer64 C:\msys64\mingw64\bin\bzip2.exe -t C:\mono-3.4.0.tar.bz2
Commit = 4484 KB = 5 MB
Work Set = 5892 KB = 6 MB
Kernel Time = 0.249 = 0%
User Time = 36.192 = 96%
Process Time = 36.441 = 97%
Global Time = 37.331 = 100%
MSYS version compliled with GCC 4.9.2, MINGW - with 4.8.2 and is faster.
Openssl "speed" benchmark with "openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048" command:
MINGW64 (mg)
///
OpenSSL 1.0.1j 15 Oct 2014
built on: Wed Oct 15 23:34:04 MSK 2014
options:bn(64,64) rc4(16x,int) des(idx,cisc,2,long) aes(partial) idea(int) blowfish(idx)
compiler: gcc -D_WINDLL -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -DL_ENDIAN -O3 -Wall -DWIN32_LEAN_AND_MEAN -DUNICODE -D_UNICODE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
MSYS2 (ms)
///
OpenSSL 1.0.1j 15 Oct 2014
built on: Wed Nov 5 20:37:48 AST 2014
options:bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) blowfish(idx)
compiler: gcc -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -O3 -Wall
My old local version (lc)
///
OpenSSL 1.0.1c 10 May 2012
built on: Sat Dec 15 16:03:48 2012
options:bn(64,32) rc4(8x,mmx) des(idx,cisc,2,long) aes(partial) idea(int) blowfish(idx)
compiler: cl /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE
-DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE
The 'numbers' are in 1000s of bytes per second processed.
Ambiguous results :)