I'm also confused about the difference between the shells, and which to use, even after reading the wiki, which currently says: "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." Here are some specific confusions:
=== I have been running pacman from the mingw shells and it seems to work fine, opposite to what the wiki suggests. Does it really matter which shell is used to run pacman? Do I really need to open an msys2 shell to run pacman?
=== I take it that if I want to build a 32-bit exe, I should do so within mingw32 shell, and if I want to build a 64-bit exe, I should do so within mingw64 shell, but is it correct that with -m32 or -m64 compiler flags, or something like that, either architecture can be built from either mingw shell?
=== As a user, do I ever need to use the msys2 shell? Is the msys2 shell pretty much for developers wanting to develop new msys2 packages?
=== What does it mean by using mingw shells for "other tasks". That's just too vague to be helpful. Does "other tasks" include running pacman? If so, the the description about msys2 is misleading.
Bottom line, it would be nice if the wiki was clearer and more directly related to what a user needs to know. I would take a stab at editing it, I can write well, but I don't know the answers. I can at least point out the problem areas and unanswered issues, as a user trying to understand msys2.
Thanks,
Daniel
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't speak for all users, I expect some want to develop msys2 software or shell scripts or python or whatever and all that can be done without using native mingw-w64 software .. It depends. If you only need to run bits of mingw-w64 software occasionally then using the full path to it will sometimes work ok.
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).
Users who use MSYS2 to build their own native software are better off writing PKGBUILD scripts for it anyway and using makepkg-mingw from the msys2_shell. THis is just my opinion though.
We don't provide multilib builds of GCC so you can't use -m32 and -m64. At present multilib GCCs would compromise the choice of exception handling as it's not possible to specify different types for each arch.
Practically speaking, you can transform an msys2 shell into a mingw-w64 x86_64 shell for the execution of some-command as follows:
MSYSTEM=MINGW64 . /etc/profile && some-command
If you look at /etc/profile, you'll see the env. variables that define the 'shell'. They are:
MSYSTEM PATH PKG_CONFIG_PATH ACLOCAL_PATH MANPATH
Maybe we should write shell functions to switch the shells, that way it wouldn't seem like such a big upfront choice?
You are welcome to submit suggested changes for the wiki to the msys2-users mailing list, or even open issues here since the formatting won't get mangled.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, if you can use any shell to run pacman, the the wiki seems
misleading, because it says "Use msys2 shell for running pacman, ...".
I don't understand the sed example you offer. I ran pacman -S sed in
all three shells, let it reinstall, and at the end there is still just
one sed.exe under the msys2 root (actually two, in /usr/bin and /bin
locations, but they are identical). And each time it installs, it's
exactly the same file (same md5sum). I guess it's re-installing from
the cache directory. Anyway, I don't see how a post-install script could
run the wrong variant, because there seems only one variant.
I'm not saying you're wrong. You know better than me, I'm just reporting
what I see. If there are really are potential problems, pacman should
probably issue a warning when it starts up from a mingw shell.
Here's a stab (probably wrong, but it's the format and question that matter):
=========================================
Which mintty shell (mingw32, mingw64, or mys2) should I use?
mingw32 - to build 32-bit windows executables.
mingw64 - to build 64-bit windows executables.
msys2 - to run makepkg and makepkg-mingw.
=========================================
OR
=========================================
Which mintty shell (mingw32, mingw64, or mys2) should I use?
run makepkg and makepkg-mingw - msys2
build 32-bit windows executables - mingw32
build 64-bit windows executables - mingw64
run commands and run scripts - any shell
run pacman for updating packages - any shell (?)
=========================================
Are you saying that if I write a program to run under windows, I should
use PKGBUILD and makepkg-mingw? If yes, maybe that would be a topic for
the wiki, to explain the advantages over using shell scripts and make
(what I'm used to using). I had the (possibly wrong) idea that PKGBUILD
was just used by msys2 developers to add packages.
Directly related to the above paragraph, what do you mean by "build their
own native software"? Native windows? Native msys2? Something else?
Thanks for clarifying cannot use -m32 and -m64 flags. That's OK with
me. Here's a possible suggestion, have a FAQ or wiki section "Places
where msys2 reported to differ from man page". Anytime one is reported,
just add it, with a brief explanation. I can start off with three possible
examples: 1) ln -s makes a copy 2) gcc @file requires windows paths 3)
-m32 -m64 don't work
Thanks for mentioning the mailing list. I kind of assumed this forum
was it. What's the different purpose, if any, between the msys2-users
mailing list and this forum? Are they both for msys2 users? If the same
kinds of questions are asked on each, is there any chance you should
just have one or the other? A few users might even search the archives
before asking a question. It only takes the half the time to search
one archive instead of two. And how is one to know which (discussion or
mailing list) to post to? As you mention, I did find the formatting on
this forum a little problematic, as it allows lots of fancy formatting,
italics, bulleted lists, tables, etc., which seem rarely needed, but
has a hard time dealing with straight text sometimes. it's even happening
on this post with the = lines. :( On the other hand, I like the avatars,
there are perhaps other advantages to the discussion format.
I'm not trying to criticize, I'm trying to offer help. msys2 seems great.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First of all, it's good to understand distinctions between MSYS2 and MINGW.
MSYS2
MSYS2 is based on Cygwin and knows how to understand POSIX conventions like paths (/usr/bin/, /etc) as well as special devices like /dev/null, /dev/clipboard, etc and many other things. MSYS2 comes with a GCC toolchain who will produce native binaries that are always tied to msys-2.0.dll. It's that DLL that does all the magic of interoperability between POSIX conventions and Windows. It's because of it that it's possible to use a Unix like path /home/joe/ and pass it to a Windows and it still works.
Indeed, (I'm not sure of the exact details) but when when msys-2.0.dll
sees you are calling a native Windows executables (one that does not
depends on msys-2.0.dll), it will convert the path /home/joe/ to a
Windows path like C:\Users\joe that the native Windows program receives
and knows how to understand. Without this translation, the Windows program
would receive /home/joe/ and wouldn't understand how to treat it
correctly. All this paths translations applies also to environment
variables.
This process (and all the POSIX emulation layer) incurs a performance
penalty that can be significant for heavy file-centric software. Git is a
good example and that's why the MSYS2 git package (msys/git) is slower
than a native git client like the one provided by Git For Windows
(git-for-windows/mingw-w64-x86_64-git). That's why a native program (read
a MINGW one) is usually "better" than an MSYS2 one. Don't be afraid of
using pure MSYS2 program, in most cases (I would say 90%), the difference
is not significant because bottleneck is not the filesystem (CPU, network,
other).
That's why you will often read that MSYS2 is only a way to make it easier
to build and deploy MINGW native executables. In my personal opinion and
the way I use it, it's much much more than that as I use and build little
MINGW tools. MSYS2 is a full subsystem dealing with way more than just a
toolchain as it deals with filesystem, users, permissions (to an extent)
and much more. I use it mainly because it has the same toolset as the one
I'm used on Linux (console-based of course :)).
Because MSYS2 understands POSIX and has a pretty good emulation layer, it
is often very easy to port a package originally built on Linux to it,
because almost no code work is needed.
MINGW
MINGW (either 32 or 64) is a set of toolchain to build native Windows
program. Those program do not depends on msys-2.0.dll and depends rather
on MSVC runtime. Those don't understand POSIX paths, so if you pass /home/joe outside of an MSYS2 shells (from pure cmd for example), it will
not understand it. Indeed, in pure cmd (and via many interactions from
other programs), no translation of paths is performed.
MINGW toolchains are based on mingw-w64 which
provides the ground work to compile them. They are available in pacman for
installation and they also contains GCC et related tools (binutils, ld).
When invoked, GCC produces pure native executable. So, when working with a
MINGW program, remember that it's like a native Window program that knows
nothing about MSYS2.
MSYS2 happens to actual provides those toolchains directly to you
pre-compiled via pacman. Note however, that it's possible to download the
mingw-w64 toolchains in standalone, put them somewhere and invoke them
afterward in MSYS2 (by proprely configuring PATH and other variables
yourself). They can also be invoked via cmd directly because they do not
depend on MSYS2 at all.
Shells
When you start any of the MSYS2 shells, they all start an MSYS2 bash
program. Since it's a MSYS2 bash, it understands Unix paths and will do
translation when calling native Windows executables.
That being said, what is the difference between all the shells? It all
about the tweaking some environment variables to change default programs
picked when calling them. It's mainly about the PATH environment variable
but it also involves MSYSTEM PKG_CONFIG_PATH ACLOCAL_PATH MANPATH like Ray
said earlier. Checkout /etc/profile around line 28 to see the conditional
that sets all this.
Let's assume you have installed three toolchains:
* MSYS2 (package group msys2-devel) to compile MSYS2 tools which
installs gcc in /usr/bin.
* MINGW32 (package group mingw-w64-i686-toolchain) to compile Windows
native 32 bits executable which installs gcc in /mingw32/bin.
* MINGW64 (package group mingw-w64-x86_64-toolchain) to compile
Windows native 64 bits executable which installs gcc in /mingw64/bin.
For msys2_shell, PATH is roughly only /usr/local/bin:/usr/bin:/bin. This
means that when running gcc, you will get /usr/bin/gcc.
For mingw32_shell, PATH is roughly /mingw32/bin:/usr/local/bin:/usr/bin:/bin. This means that now, running gcc you will get instead /mingw32/bin/gcc.
For mingw64_shell, PATH is roughly /mingw64/bin:/usr/local/bin:/usr/bin:/bin and as you have guessed,
running gcc you will get instead /mingw64/bin/gcc.
This means that all three shells have the same capabilities, but because of
the different orders, tools that will be picked are different. So, if you
want to compile something, use the appropriate shell for what you want to
do (MSYS2 program, Windows native 32 bits or Windows native 64 bits).
If you are not compiling anything, then it depends. Usually, msys2_shell is
recommended. However, on a bare installation, /mingw64/bin is not added
anywhere when using msys2_shell, problem it can causes is that if you had
installed mingw64 packages, they are not available in the shell. In my
case, I have tweaked by .bash_profile to correctly add /mingw64/bin after PATH (like /usr/local/bin:/usr/bin:/bin:/mingw64/bin). This
always favor MSYS2 tools but will pick /mingw64/bin when they don't exist
in MSYS2 /usr/bin.
Dual Packages
Then, it all comes to the problem that sometimes, programs exist in both
variant, i.e. an MSYS2 version and a MINGW version. That the case with curl (and others). There is two packages for it (three if you include the
32 bits version):
MSYS2 package is msys/curl while mingw64 package is mingw64/mingw-w64-x86_64-curl.
When running pacman curl in any of the shells, it will always pick the msys one by default. Now, let's say you installed both of them:
pacman -S msys/curl # Executable at /usr/bin/curl
pacman -S mingw64/mingw-w64-x86_64-curl # Executable at /mingw64/bin/curl
Now, depending on the shell you start with, the curl that will be picked
will be different. And here comes the advise to use msys2 shell for
pacman tasks. If a package does a post-install and uses curl, it might
get the wrong one depending on the shell you used. It can be used with mingw64_shell, just need more care on some (I think rare) cases. Indeed,
even using the mingw64 could yield the correct results, thanks to path
conversion, so, it's hard to come with a sound real existing example.
I think sed was a wrong example as I see only one package for it pacsearch sed. I might be wrong but potential problems still stand for
other packages.
Packages
Whether you want to package a MSYS2 program or MINGW one, both uses
PKGBUILD. It's just the toolchain used to do the steps that are different.
I think (someone would need to confirm), that makepkg-mingw takes cares
of setuping the PATH and all other variables. So even in msys2 shell,
it would pick the correct toolchain. I really don't know the pros and cons
of using either the shells or the makepkg-mingw tool however.
It's a pretty long post now. Don't hesitate to break it down and ask
specific clarifications about portion of it. I will try my best to help you
out.
Sorry if I explain stuff you already knew.
Hope if helped you clarify all this. MSYS2 and related tooling like MINGW.
It's a big beast but understanding every parts will make you usage more
pleasant ... and will help you further understand other problems you might
have and also debug problems you got with tooling interacting with MSYS2
subsystem and MINGW programs.
Well, if you can use any shell to run pacman, the the wiki seems
misleading, because it says "Use msys2 shell for running pacman, ...".
I don't understand the sed example you offer. I ran pacman -S sed in
all three shells, let it reinstall, and at the end there is still just
one sed.exe under the msys2 root (actually two, in /usr/bin and /bin
locations, but they are identical). And each time it installs, it's
exactly the same file (same md5sum). I guess it's re-installing from
the cache directory. Anyway, I don't see how a post-install script could
run the wrong variant, because there seems only one variant.
I'm not saying you're wrong. You know better than me, I'm just reporting
what I see. If there are really are potential problems, pacman should
probably issue a warning when it starts up from a mingw shell.
Here's a stab (probably wrong, but it's the format and question that
matter):
=========================================
Which mintty shell (mingw32, mingw64, or mys2) should I use?
mingw32 - to build 32-bit windows executables.
mingw64 - to build 64-bit windows executables.
msys2 - to run makepkg and makepkg-mingw.
=========================================
OR
=========================================
Which mintty shell (mingw32, mingw64, or mys2) should I use?
run makepkg and makepkg-mingw - msys2
build 32-bit windows executables - mingw32
build 64-bit windows executables - mingw64
run commands and run scripts - any shell
run pacman for updating packages - any shell (?)
=========================================
Are you saying that if I write a program to run under windows, I should
use PKGBUILD and makepkg-mingw? If yes, maybe that would be a topic for
the wiki, to explain the advantages over using shell scripts and make
(what I'm used to using). I had the (possibly wrong) idea that PKGBUILD
was just used by msys2 developers to add packages.
Directly related to the above paragraph, what do you mean by "build their
own native software"? Native windows? Native msys2? Something else?
Thanks for clarifying cannot use -m32 and -m64 flags. That's OK with
me. Here's a possible suggestion, have a FAQ or wiki section "Places
where msys2 reported to differ from man page". Anytime one is reported,
just add it, with a brief explanation. I can start off with three possible
examples: 1) ln -s makes a copy 2) gcc @file requires windows paths 3)
-m32 -m64 don't work
Thanks for mentioning the mailing list. I kind of assumed this forum
was it. What's the different purpose, if any, between the msys2-users
mailing list and this forum? Are they both for msys2 users? If the same
kinds of questions are asked on each, is there any chance you should
just have one or the other? A few users might even search the archives
before asking a question. It only takes the half the time to search
one archive instead of two. And how is one to know which (discussion or
mailing list) to post to? As you mention, I did find the formatting on
this forum a little problematic, as it allows lots of fancy formatting,
italics, bulleted lists, tables, etc., which seem rarely needed, but
has a hard time dealing with straight text sometimes. it's even happening
on this post with the = lines. :( On the other hand, I like the avatars,
there are perhaps other advantages to the discussion format.
I'm not trying to criticize, I'm trying to offer help. msys2 seems great.
Thanks very much for the detailed, helpful response. I carefully read it and learned a lot. I think other new users would benefit from reading it. If I have any other questions, I'll make a separate post. Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There's also a new project called Midipix, which hopes to unite the worlds of native Windows and POSIX-y Windows. It will be interesting to see how it progresses.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What is the difference between these shells and which I should use?
All is described in wiki:
http://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/
I'm also confused about the difference between the shells, and which to use, even after reading the wiki, which currently says: "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." Here are some specific confusions:
=== I have been running pacman from the mingw shells and it seems to work fine, opposite to what the wiki suggests. Does it really matter which shell is used to run pacman? Do I really need to open an msys2 shell to run pacman?
=== I take it that if I want to build a 32-bit exe, I should do so within mingw32 shell, and if I want to build a 64-bit exe, I should do so within mingw64 shell, but is it correct that with -m32 or -m64 compiler flags, or something like that, either architecture can be built from either mingw shell?
=== As a user, do I ever need to use the msys2 shell? Is the msys2 shell pretty much for developers wanting to develop new msys2 packages?
=== What does it mean by using mingw shells for "other tasks". That's just too vague to be helpful. Does "other tasks" include running pacman? If so, the the description about msys2 is misleading.
Bottom line, it would be nice if the wiki was clearer and more directly related to what a user needs to know. I would take a stab at editing it, I can write well, but I don't know the answers. I can at least point out the problem areas and unanswered issues, as a user trying to understand msys2.
Thanks,
Daniel
I can't speak for all users, I expect some want to develop msys2 software or shell scripts or python or whatever and all that can be done without using native mingw-w64 software .. It depends. If you only need to run bits of mingw-w64 software occasionally then using the full path to it will sometimes work ok.
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).
Users who use MSYS2 to build their own native software are better off writing PKGBUILD scripts for it anyway and using makepkg-mingw from the msys2_shell. THis is just my opinion though.
We don't provide multilib builds of GCC so you can't use -m32 and -m64. At present multilib GCCs would compromise the choice of exception handling as it's not possible to specify different types for each arch.
Practically speaking, you can transform an msys2 shell into a mingw-w64 x86_64 shell for the execution of some-command as follows:
If you look at /etc/profile, you'll see the env. variables that define the 'shell'. They are:
Maybe we should write shell functions to switch the shells, that way it wouldn't seem like such a big upfront choice?
You are welcome to submit suggested changes for the wiki to the msys2-users mailing list, or even open issues here since the formatting won't get mangled.
Well, if you can use any shell to run pacman, the the wiki seems
misleading, because it says "Use msys2 shell for running pacman, ...".
I don't understand the sed example you offer. I ran pacman -S sed in
all three shells, let it reinstall, and at the end there is still just
one sed.exe under the msys2 root (actually two, in /usr/bin and /bin
locations, but they are identical). And each time it installs, it's
exactly the same file (same md5sum). I guess it's re-installing from
the cache directory. Anyway, I don't see how a post-install script could
run the wrong variant, because there seems only one variant.
I'm not saying you're wrong. You know better than me, I'm just reporting
what I see. If there are really are potential problems, pacman should
probably issue a warning when it starts up from a mingw shell.
Here's a stab (probably wrong, but it's the format and question that matter):
=========================================
Which mintty shell (mingw32, mingw64, or mys2) should I use?
mingw32 - to build 32-bit windows executables.
mingw64 - to build 64-bit windows executables.
msys2 - to run makepkg and makepkg-mingw.
=========================================
OR
=========================================
Which mintty shell (mingw32, mingw64, or mys2) should I use?
run makepkg and makepkg-mingw - msys2
build 32-bit windows executables - mingw32
build 64-bit windows executables - mingw64
run commands and run scripts - any shell
run pacman for updating packages - any shell (?)
=========================================
Are you saying that if I write a program to run under windows, I should
use PKGBUILD and makepkg-mingw? If yes, maybe that would be a topic for
the wiki, to explain the advantages over using shell scripts and make
(what I'm used to using). I had the (possibly wrong) idea that PKGBUILD
was just used by msys2 developers to add packages.
Directly related to the above paragraph, what do you mean by "build their
own native software"? Native windows? Native msys2? Something else?
Thanks for clarifying cannot use -m32 and -m64 flags. That's OK with
me. Here's a possible suggestion, have a FAQ or wiki section "Places
where msys2 reported to differ from man page". Anytime one is reported,
just add it, with a brief explanation. I can start off with three possible
examples: 1) ln -s makes a copy 2) gcc @file requires windows paths 3)
-m32 -m64 don't work
Thanks for mentioning the mailing list. I kind of assumed this forum
was it. What's the different purpose, if any, between the msys2-users
mailing list and this forum? Are they both for msys2 users? If the same
kinds of questions are asked on each, is there any chance you should
just have one or the other? A few users might even search the archives
before asking a question. It only takes the half the time to search
one archive instead of two. And how is one to know which (discussion or
mailing list) to post to? As you mention, I did find the formatting on
this forum a little problematic, as it allows lots of fancy formatting,
italics, bulleted lists, tables, etc., which seem rarely needed, but
has a hard time dealing with straight text sometimes. it's even happening
on this post with the = lines. :( On the other hand, I like the avatars,
there are perhaps other advantages to the discussion format.
I'm not trying to criticize, I'm trying to offer help. msys2 seems great.
Hi,
I will try to help you out from new bases.
First of all, it's good to understand distinctions between MSYS2 and MINGW.
MSYS2
MSYS2 is based on Cygwin and knows how to understand POSIX conventions like paths (
/usr/bin/,/etc) as well as special devices like/dev/null,/dev/clipboard, etc and many other things. MSYS2 comes with a GCC toolchain who will produce native binaries that are always tied tomsys-2.0.dll. It's that DLL that does all the magic of interoperability between POSIX conventions and Windows. It's because of it that it's possible to use a Unix like path/home/joe/and pass it to a Windows and it still works.Indeed, (I'm not sure of the exact details) but when when
msys-2.0.dllsees you are calling a native Windows executables (one that does not
depends on
msys-2.0.dll), it will convert the path/home/joe/to aWindows path like
C:\Users\joethat the native Windows program receivesand knows how to understand. Without this translation, the Windows program
would receive
/home/joe/and wouldn't understand how to treat itcorrectly. All this paths translations applies also to environment
variables.
This process (and all the POSIX emulation layer) incurs a performance
penalty that can be significant for heavy file-centric software. Git is a
good example and that's why the MSYS2 git package (
msys/git) is slowerthan a native git client like the one provided by Git For Windows
(
git-for-windows/mingw-w64-x86_64-git). That's why a native program (reada MINGW one) is usually "better" than an MSYS2 one. Don't be afraid of
using pure MSYS2 program, in most cases (I would say 90%), the difference
is not significant because bottleneck is not the filesystem (CPU, network,
other).
That's why you will often read that MSYS2 is only a way to make it easier
to build and deploy MINGW native executables. In my personal opinion and
the way I use it, it's much much more than that as I use and build little
MINGW tools. MSYS2 is a full subsystem dealing with way more than just a
toolchain as it deals with filesystem, users, permissions (to an extent)
and much more. I use it mainly because it has the same toolset as the one
I'm used on Linux (console-based of course :)).
Because MSYS2 understands POSIX and has a pretty good emulation layer, it
is often very easy to port a package originally built on Linux to it,
because almost no code work is needed.
MINGW
MINGW (either 32 or 64) is a set of toolchain to build native Windows
program. Those program do not depends on
msys-2.0.dlland depends ratheron MSVC runtime. Those don't understand POSIX paths, so if you pass
/home/joeoutside of an MSYS2 shells (from pure cmd for example), it willnot understand it. Indeed, in pure
cmd(and via many interactions fromother programs), no translation of paths is performed.
MINGW toolchains are based on mingw-w64 which
provides the ground work to compile them. They are available in pacman for
installation and they also contains GCC et related tools (binutils, ld).
When invoked, GCC produces pure native executable. So, when working with a
MINGW program, remember that it's like a native Window program that knows
nothing about MSYS2.
MSYS2 happens to actual provides those toolchains directly to you
pre-compiled via pacman. Note however, that it's possible to download the
mingw-w64 toolchains in standalone, put them somewhere and invoke them
afterward in MSYS2 (by proprely configuring PATH and other variables
yourself). They can also be invoked via
cmddirectly because they do notdepend on MSYS2 at all.
Shells
When you start any of the MSYS2 shells, they all start an MSYS2
bashprogram. Since it's a MSYS2
bash, it understands Unix paths and will dotranslation when calling native Windows executables.
That being said, what is the difference between all the shells? It all
about the tweaking some environment variables to change default programs
picked when calling them. It's mainly about the PATH environment variable
but it also involves MSYSTEM PKG_CONFIG_PATH ACLOCAL_PATH MANPATH like Ray
said earlier. Checkout
/etc/profilearound line 28 to see the conditionalthat sets all this.
Let's assume you have installed three toolchains:
* MSYS2 (package group
msys2-devel) to compile MSYS2 tools whichinstalls gcc in
/usr/bin.* MINGW32 (package group
mingw-w64-i686-toolchain) to compile Windowsnative 32 bits executable which installs gcc in
/mingw32/bin.* MINGW64 (package group
mingw-w64-x86_64-toolchain) to compileWindows native 64 bits executable which installs gcc in
/mingw64/bin.For msys2_shell, PATH is roughly only
/usr/local/bin:/usr/bin:/bin. Thismeans that when running
gcc, you will get/usr/bin/gcc.For mingw32_shell, PATH is roughly
/mingw32/bin:/usr/local/bin:/usr/bin:/bin. This means that now, runninggccyou will get instead/mingw32/bin/gcc.For mingw64_shell, PATH is roughly
/mingw64/bin:/usr/local/bin:/usr/bin:/binand as you have guessed,running
gccyou will get instead/mingw64/bin/gcc.This means that all three shells have the same capabilities, but because of
the different orders, tools that will be picked are different. So, if you
want to compile something, use the appropriate shell for what you want to
do (MSYS2 program, Windows native 32 bits or Windows native 64 bits).
If you are not compiling anything, then it depends. Usually, msys2_shell is
recommended. However, on a bare installation,
/mingw64/binis not addedanywhere when using
msys2_shell, problem it can causes is that if you hadinstalled mingw64 packages, they are not available in the shell. In my
case, I have tweaked by
.bash_profileto correctly add/mingw64/binafter PATH (like
/usr/local/bin:/usr/bin:/bin:/mingw64/bin). Thisalways favor MSYS2 tools but will pick
/mingw64/binwhen they don't existin MSYS2
/usr/bin.Dual Packages
Then, it all comes to the problem that sometimes, programs exist in both
variant, i.e. an MSYS2 version and a MINGW version. That the case with
curl(and others). There is two packages for it (three if you include the32 bits version):
msys/curlwhile mingw64 package ismingw64/mingw-w64-x86_64-curl.When running
pacman curlin any of the shells, it will always pick themsysone by default. Now, let's say you installed both of them:/usr/bin/curl/mingw64/bin/curlNow, depending on the shell you start with, the
curlthat will be pickedwill be different. And here comes the advise to use
msys2shell forpacman tasks. If a package does a post-install and uses
curl, it mightget the wrong one depending on the shell you used. It can be used with
mingw64_shell, just need more care on some (I think rare) cases. Indeed,even using the
mingw64could yield the correct results, thanks to pathconversion, so, it's hard to come with a sound real existing example.
I think
sedwas a wrong example as I see only one package for itpacsearch sed. I might be wrong but potential problems still stand forother packages.
Packages
Whether you want to package a MSYS2 program or MINGW one, both uses
PKGBUILD. It's just the toolchain used to do the steps that are different.
I think (someone would need to confirm), that
makepkg-mingwtakes caresof setuping the
PATHand all other variables. So even inmsys2shell,it would pick the correct toolchain. I really don't know the pros and cons
of using either the shells or the
makepkg-mingwtool however.It's a pretty long post now. Don't hesitate to break it down and ask
specific clarifications about portion of it. I will try my best to help you
out.
Sorry if I explain stuff you already knew.
Hope if helped you clarify all this. MSYS2 and related tooling like MINGW.
It's a big beast but understanding every parts will make you usage more
pleasant ... and will help you further understand other problems you might
have and also debug problems you got with tooling interacting with MSYS2
subsystem and MINGW programs.
Regard,
Matt
On Sun, Nov 1, 2015 at 12:09 AM DanAaronGoldman danaarongoldman@users.sf.net wrote:
Last edit: Matthieu Vachon 2015-11-18
Thanks Matt very much for this detailed explanation. I put a link to it on our wiki homepage. Hope you don't mind.
Thanks very much for the detailed, helpful response. I carefully read it and learned a lot. I think other new users would benefit from reading it. If I have any other questions, I'll make a separate post. Thanks again.
There's also a new project called Midipix, which hopes to unite the worlds of native Windows and POSIX-y Windows. It will be interesting to see how it progresses.
Thanks Ray for the pointer to Midipix. Never heard about it before. I too will look at more closely in the future.
Cheers,
Matt