MSYS2 Shell or MinGW-w64 Shell

• 

  Ivan Goncharuk -   2015-08-21

  What is the difference between these shells and which I should use?

   

  • 
    

• 

  Alexx83 -   2015-08-21

  All is described in wiki:
  http://sourceforge.net/p/msys2/wiki/MSYS2%20introduction/

   

  • 
    

• 

  DanAaronGoldman -   2015-10-31

  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

   

  • 
    

• 

  Ray Donnelly -   2015-11-01

  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.

   

  • 
    

• 

  DanAaronGoldman -   2015-11-01

  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.

   

  • 
    

  • 

    Matthieu Vachon -   2015-11-02

    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 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.

    Regard,
    Matt

    On 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 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.

    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

    • 
      

    • 

      David Macek -   2015-11-17

      Thanks Matt very much for this detailed explanation. I put a link to it on our wiki homepage. Hope you don't mind.

       

      • 
        

• 

  DanAaronGoldman -   2015-11-02

  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.

   

  • 
    

• 

  Ray Donnelly -   2015-11-02

  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.

   

  • 
    

• 

  Matthieu Vachon -   2015-11-02

  Thanks Ray for the pointer to Midipix. Never heard about it before. I too will look at more closely in the future.

  Cheers,
  Matt

   

  •