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:
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.
-
-
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 workThanks 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.dll
sees you are calling a native Windows executables (one that does not
depends onmsys-2.0.dll
), it will convert the path/home/joe/
to a
Windows path likeC:\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 onmsys-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 purecmd
(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 viacmd
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 MSYS2bash
, 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 groupmsys2-devel
) to compile MSYS2 tools which
installs gcc in/usr/bin
.
* MINGW32 (package groupmingw-w64-i686-toolchain
) to compile Windows
native 32 bits executable which installs gcc in/mingw32/bin
.
* MINGW64 (package groupmingw-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 runninggcc
, 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,
runninggcc
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 usingmsys2_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 usemsys2
shell for
pacman tasks. If a package does a post-install and usescurl
, 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 themingw64
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), thatmakepkg-mingw
takes cares
of setuping thePATH
and all other variables. So even inmsys2
shell,
it would pick the correct toolchain. I really don't know the pros and cons
of using either the shells or themakepkg-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.Regard,
MattOn Sun, Nov 1, 2015 at 12:09 AM DanAaronGoldman danaarongoldman@users.sf.net wrote:
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 workThanks 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.
MSYS2 Shell or MinGW-w64 Shell
https://sourceforge.net/p/msys2/discussion/general/thread/dcf8f4d3/?limit=25#8473
Sent from sourceforge.net because you indicated interest in
https://sourceforge.net/p/msys2/discussion/general/To unsubscribe from further messages, please visit
https://sourceforge.net/auth/subscriptions/
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.
-
- MSYS2 package is
-
-
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 -