HOWTO Create an MSYS Build Environment

Important Note: The build environment described here is used for development of the MSYS product itself; it is not applicable for users who simply wish to use MSYS, as a working environment for developing normal MS-Windows applications, (presumably using MinGW as the compiler suite). The overwhelming majority of MSYS users do not need to set up any such "MSYS Build Environment".

The MSYS build environment is one whose GNU canonical system name (like returned by "uname -s") will have MSYS_ as the beginning portion of the string. The MSYS build environment is used to build the tools distributed by MSYS. The binaries it creates are dependent on the msys-1.0.dll runtime, which provides thin POSIX layer.

The easiest way to make sure all necessary packages are installed is to let mingw-get do the job:

mingw-get install msys-dvlpr

By default, MSYS gets installed into <MinGW_root>\msys\1.0 and can be entered executing "msys.bat MSYS" from there. That will open new window with MSYS in its title and different color scheme if rxvt is used. In MSYS environment $PATH is set so /bin preceedes /mingw/bin, therefore msys-gcc becomes default compiler (gcc -v should state "msys special").

On the contrary in MinGW environment (entered executing "msys.bat" without parameter) /mingw/bin path preceedes /bin, therefore mingw32-gcc is found first, thus gcc -v states "GCC").

To help identify the runtime build and the the current working directory, following can be added to ~/.profile file.

# Determine windows path
W=`pwd -W`

# Determine identifying version info
V=`echo -n \`uname -r | cut -d \( -f 1\`-\`uname -v | sed -e 's/ /@/'\``

# Reset bash prompt
export PS1='\[\033]0;$MSYSTEM-$V($W):\w\007
\033[47m\033[30m\]\u@\h \[\033[47m\033[35m\w\033[0m\]
$ '

Similar profile commands can be established on remote systems to help identify the remote window in the task bar.

See also the following for more hints and suggestions:

[FIXME: these references all point to the old, now-deprecated MinGWiki; the original pages need to be migrated].

MinGW/MSYS Source Forge home page:

Re: HOWTO Create an MSYS Build Environment

You may want to consider setting up Security on your wiki as on Feb 2 "wow_account" revised your article with spam.

I reverted it back to your previous post which I find much more valuable than how to get "cheap wow accounts" :-)

Re: HOWTO Create an MSYS Build Environment

keith's picture

Thanks for that.

Yes, we know we have a security problem: I have been removing inappropriate "wow" related junk since around Christmas 2008, and blocking the accounts used to create it; ("wow_account" has been blocked for several days). Unfortunately, SourceForge have blocked the communications channels required to establish user bona-fides, when an account is created; thus we are forced to either:--

  • Allow any user to create an account, and immediately create or modify wiki content, without additional validation; (this is the current configuration).
  • Allow any user to create an account, but require them to submit all proposed postings for approval, until such time as they have demonstrated trustworthiness.

If the wiki abuse continues, we may have to adopt the latter policy; however, while the spam remains manageable, we prefer not to do so, as this would not be in the wiki spirit of publicly co-operative site maintenance.

Re: HOWTO Create an MSYS Build Environment

Thanks for writing this up. I'm pretty green yet in regards to msys, mingw, makefiles, etc and built bash on my 1st attempt.

Now if only I could find some info on config.guess supporting MSYS_NT-6.0 (ie server 2008) to build libglade... hmmm.

Thanks again!


Re: HOWTO Create an MSYS Build Environment

I don't know if this will help you, but you might get some hints by comparing the config.guess files between an MSYS package and the "standard" Gnu version. Try MSYS Bash and standard Gnu Bash for instance.

Re: HOWTO Create an MSYS Build Environment


The links to flex, bison and bash are broken.


Re: HOWTO Create an MSYS Build Environment

keith's picture

I don't think they were intended to be links; the MediaWiki filter apparently misidentified them. I've adjusted the formatting, based on this assumption.

Re: HOWTO Create an MSYS Build Environment

Yes, they were not intended to be links and I didn't know how to fix thm. I think some kind soul has done so for me. Thanks to that person!

Re: HOWTO Create an MSYS Build Environment

I tried running flex soon after installing flex and bison. It gave me an error message saying "The application has failed to start because msys-regex-0.dll was not found. Re-installing the application may fix this problem." I guess something more needs to be specified in the steps mentioned here.
Installing regex 0.12 resolves the issue. I have modified the steps to include this package.

Re: HOWTO Create an MSYS Build Environment

keith's picture


For some strange reason,
the MSYS build environment doesn't like building in the same folder
as the source code (did I read this correctly???)

It's actually dependent on the source package you are building; some will allow building in the source directory, some will not. IIRC, GCC itself will not even permit building in any subdirectory of the source tree.

However, why do you consider this strange? It is, in fact, good practice to always build in a different directory from the source; any package which does not support such building, (commonly known as `VPATH' or `out-of-source' building), is deficient, IMO.

Directing you to build in a separate directory is merely encouraging good practice.

Re: HOWTO Create an MSYS Build Environment

I thought it was strange compared to the many, many Linux packages that I have "built" following the standard "tar, configure, make" routine.

I think I was being a bit imprecise here; by "built" I meant run "configure" and "make". I don't ever recall having to create a subdirectory of the untar'd package in order to run configure from.

In particular, I have built bash on Linux and didn't need to create a subdirectory to run configure and make in. Hence, it seemed strange to find that for MSYS it was suggested to do so. Or, have I've completely mis-read something and that's not what it meant at all?

Re: HOWTO Create an MSYS Build Environment

keith's picture

Sorry for the delay -- I missed this follow up, when you posted it.

I think it strange that you even consider building "in-source"; there are so many advantages to keeping the build and source directories separate, that I just use this technique as a matter of course. Sure, there are many packages which will support building either way, and it is a matter of personal preference which you choose; there are, however, some packages which simply cannot be built "in-source", under any circumstances, while there are others, (broken, IMO), which can only be built "in-source".

As to why some packages can be built "in-source" on GNU/Linux, but require "out-of-source" building on MS-Windows, there can be any number of reasons for this. One, which immediately comes to mind, is make-goal conflicts introduced by the case insensitive nature of the MS-Windows file system; autoconf is one package which exhibits such a conflict, requiring an "out-of-source" build on MS-Windows, where GNU/Linux can happily support building either in or out-of source.

A further point: you say "I don't recall ever having to create a subdirectory of the untarred package...". You should not do this anyway; it is better to create the build directory as a sibling of the top level source directory, not as a descendant of it. (In fact, if you ever try to build GCC "in-source", or in any descendant of the top level source directory, then your build will fail miserably, on any platform).

Re: HOWTO Create an MSYS Build Environment

I also missed your posting.

Whilst a long-time user of Linux, I'm relatively new to building applications on Linux, so naturally I tend to follow the build and installation instructions supplied with the tar.gz packages. I'd be first to admit my memory isn't perfect, but as far as I remember, almost all of them imply that you should build "in-source", which is why I thought it strange to create a separate build directory.

Here are a couple of examples:

--------------------------Python 2.6.1--------------------------

To start building right away (on UNIX): type "./configure" in the
current directory and when it finishes, type "make". This creates an
executable "./python"; to install in /usr/local, first do "su root"
and then "make install".

--------------------------Bash 4.0.rc1--------------------------Basic Installation


These are installation instructions for Bash.

The simplest way to compile Bash is:

  1. `cd' to the directory containing the source code and type
     `./configure' to configure Bash for your system.  If you're using
     `csh' on an old version of System V, you might need to type `sh
     ./configure' instead to prevent `csh' from trying to execute
     `configure' itself.

     Running `configure' takes some time.  While running, it prints
     messages telling which features it is checking for.

  2. Type `make' to compile Bash and build the `bashbug' bug reporting

It's these types of instructions that made me regard building "in-source" to be "standard". Should these instructions be considered as being in need of improvement?

I do, however, accept your point that it is good practise to keep the source tree clean, so I do try to do so when possible.

Regarding your comment regarding the sibling directory, I was referring to the my_build directory in the following:


and when I said "subdirectory", I meant a descendant of /home/<user_name>/bash-3.1-MSYS-1.0.11-1 - the "top level package directory". Did you mean that it should be a sibling of


?? If I understand correctly what you mean by "top level source directory", /home/<user_name>/bash-3.1-MSYS-1.0.11-1/my_build is a sibling of it, and /home/<user_name>/bash-3.1-MSYS-1.0.11-1 is what I call the "top level package directory" that contains the "top level source directory". Or is your "top level source directory" what I refer to as the "top level package directory"?

Re: HOWTO Create an MSYS Build Environment

keith's picture

Saying that you may build in-source doesn't necessarily imply that you should, but yes, those packages which suggest this practice do their users a disservice, IMO; the advantages of an out-of-source build are much too significant, to be dismissed in such cavalier fashion. I consider any package which cannot be built out-of-source to be broken.

Conversely, there are some packages which simply cannot be built in-source. GCC is one such; try it, and it will fail spectacularly. Even trying to build it at any subdirectory level within its source tree will result in guaranteed failure.

By sibling, I mean a directory with the same parent as the top level directory in the individual package's source tree. I typically set it up like this:

   :-- foo-package
   :-- build
   :     :
   :     :-- foo-package
   :     :

(where "build" is a sibling of "foo-package", and therefore, "build/foo-package" is a nephew), and then do:

$ cd all-package-sources/build/foo-package
$ ../../foo-package/configure ...

but it doesn't need to be that immediate; you could even have the source tree on a read-only file system, and should still be able to build, with the build tree on a completely different file system device.

This wiki is not a forum for discussion of usage issues. Please use the list instead. We do not allow creation of comments by anonymous or untrusted users, on any page.
Site Status

Site maintenance performed successfully, site online Dec 13th 12:00 AM Eastern.