MSYS/MinGW: separate installations suddenly sharing mount points

[LigH]

To compile x265 with different GNU C/C++ compiler versions, I have placed separate installations of MSYS/MinGW based on the full archives provided by XhmikosR. The installation for GCC 6.2.0 contains an update archive provided by El Heggunte.

The MSYS/MinGW installation for GCC 5.3.0 is located in H:\MSYS-GCC530
The MSYS/MinGW installation for GCC 6.2.0 is located in H:\MSYS-GCC620

I am really really sure that I used to open both shells (each with "msys.bat --mintty") and could run shell script driven updates and compilations separately in their respective home directories.

Today I updated TortoiseHG and CMake.

Suddenly, both shells share the same mount point. Which, depends on which of them was started first.

H:\MSYS-GCC530\msys.bat --mintty
H:\MSYS-GCC620\msys.bat --mintty

According to ProcessExplorer, ...

"H:\MSYS-GCC530\\bin\mintty /bin/bash -l" runs in "H:\MSYS-GCC530" and executed "H:\MSYS-GCC530\bin\bash.exe" in "H:\MSYS-GCC530\home\user"
"H:\MSYS-GCC620\\bin\mintty /bin/bash -l" runs in "H:\MSYS-GCC620" and executed "H:\MSYS-GCC530\bin\bash.exe" in "H:\MSYS-GCC530\home\user"

Both report:
$ mount
H:\MSYS-GCC530 on /usr type user (binmode,noumount)
H:\MSYS-GCC530 on / type user (binmode,noumount)
...

Opposite order:

H:\MSYS-GCC620\msys.bat --mintty
H:\MSYS-GCC530\msys.bat --mintty

According to ProcessExplorer, ...

"H:\MSYS-GCC620\\bin\mintty /bin/bash -l" runs in "H:\MSYS-GCC620" and executed "H:\MSYS-GCC620\bin\bash.exe" in "H:\MSYS-GCC620\home\user"
"H:\MSYS-GCC530\\bin\mintty /bin/bash -l" runs in "H:\MSYS-GCC530" and executed "H:\MSYS-GCC620\bin\bash.exe" in "H:\MSYS-GCC620\home\user"

Both report:
$ mount
H:\MSYS-GCC620 on /usr type user (binmode,noumount)
H:\MSYS-GCC620 on / type user (binmode,noumount)
...

Is it possible to separate their environments again, as it used to be until today? I would like to see:

"H:\MSYS-GCC530\\bin\mintty /bin/bash -l" runs in "H:\MSYS-GCC530" and executed "H:\MSYS-GCC530\bin\bash.exe" in "H:\MSYS-GCC530\home\user"
"H:\MSYS-GCC620\\bin\mintty /bin/bash -l" runs in "H:\MSYS-GCC620" and executed "H:\MSYS-GCC620\bin\bash.exe" in "H:\MSYS-GCC620\home\user"

If not, I would have to quit the shell where I compiled with GCC 5.3.0 before I open the shell to compile with GCC 6.2.0; this reduces the efficiency from today on.

I can not even imagine a reason why it happened so suddenly.

[filler56789]

Sorry, I don't know the solution to the problem :-/

But, FWIW:

1) XhmikosR has already released his GCC 6.2 MSYS toolchain;

2) MSYS2 has had a similar issue. In the beginning, I included B:\CMake, B:\GIT and B:\Mercurial in Windows's PATH, and MSYS2 was happy... But one fine day, MSYS2 became unable to find CMake, GIT and Mercurial :confused: So I had to move those directories into MSYS2's "rootdir" and then edit .bash_profile:

PATH=/commons:/CMAKE:/MERCURIAL/:/GIT:$PATH
export PATH

3) releasing binaries compiled with different versions of GCC...
¿is it still worth the hassle? :confused:

[clsid]

mount shows correct folders here with two different instances.

Using bundles from here:
http://xhmikosr.1f0.de/tools/msys/

Simply extract and edit /etc/fstab for correct mingw mount point.

[LigH]

1) XhmikosR was a little late. But I will consider exchanging the content.

2) I did not use an explicit /etc/fstab in either MSYS, and it used to work fine until yesterday. I wonder if the reason is somewhere in the new CMake installer, as I uninstalled an older version to ensure the current v3.6.2 has no issues with an older installed version, just in case it was old enough to be covered by the warning on the download site. I did not let it add its path this time, maybe I should, for the current user account.

3) Little hassle when done scripted. But possibly useful; sometimes I read about strange decisions regarding the development of development software in a blog about security, conspiracies, and other "unusual news".
__

P.S.:

I noticed empty /etc/fstab files (0 bytes) today, which I missed to notice before. May they have been part of the reason? — I'll see soon. I deleted both environments and unpacked them again, and XhmikosR did not include empty files in his packages. Now cloning x265 again...

[filler56789]

2) I did not use an explicit /etc/fstab in either MSYS, and it used to work fine until yesterday. I wonder if the reason is somewhere in the new CMake installer, as I uninstalled an older version to ensure the current v3.6.2 has no issues with an older installed version, just in case it was old enough to be covered by the warning on the download site. I did not let it add its path this time, maybe I should, for the current user account.

Well, I learned to mistrust and to distrust installers, so I cannot help you with that :o

Anyway: one thing I noticed in the "latest and greatest" versions of CMake: they are (MORE) bloated, and they don't work at all if I move the main files from the \bin subdir to the \CMake rootdir. In this way, I'm afraid I'll keep using the olde and goode version 2.8.12.2 "forever" :-/

[LigH]

I don't believe that CMake is the main reason here. I rather suspect a feature that seems to test when a new instance of a console or shell process is loaded, if there is already another running in RAM which it can be attached to. Somehow I was lucky earlier that this did not work... :o

If you execute "ps -ef" in either console, you can see that the MinGW environment knows both mintty processes (one as /usr/bin/mintty, the other as /h/MSYS-GCC{530|620}/bin/mintty). I wonder if the reason may be in auto-mounting Windows drives, and if I could avoid that. Or if I can otherwise avoid both mintty instances sharing a common environment. For a specific reason, this was the default until yesterday.