Revision of MSYS from 2009, July 23 - 02:54

An example would be building a library that uses the autotools build system. Users will typically run "./configure" then "make" to build it. The configure shell script requires a shell script interpreter which is not present on Windows systems, but provided by MSYS.

A common misunderstanding is MSYS is "UNIX on Windows", MSYS by itself does not contain a compiler or a C library, therefore does not give the ability to magically port UNIX programs over to Windows nor does it provide any UNIX specific functionality like case-sensitive filenames. Users looking for such functionality should look to Cygwin or Microsoft's Interix instead.

Installing MSYS

These instructions were based on the Enlightenment Wiki. Thanks to Vincent Torri for pointing them out.

The total size of the installation of MSYS/MinGW is around 110 MB. Be sure to have enough space on your hard disk.

If you haven't already installed MinGW on your system, install MinGW in C:\MinGW. It is better to not install it in the same directory than MSYS, though there should be no problem since MSYS 1.0.11. In the installer, choose "Download and install", then "Current" (it will install gcc 4.4.0).

Install MSYS 1.0.11. I usually install it in C:\msys\1.0, but you can use any directory that you prefer.

Next, the post install process will ask for the directory where MinGW was installed to. Enter "c:/mingw". If you make a mistake, you can change it by editing the "C:\msys\1.0\etc\fstab" file, make sure to use 'LF line endings. An example fstab may contain:

Install them with the 3 with the following command (avoid building in the source tree if possible):

../path/to/configure --prefix=/mingw && make && make install

If make seems to be stuck in an infinite loop, csmake should probably be used instead.

csmake is now part of MSYS 1.0.11, installed as "make"

As all the libraries will be installed in /mingw, PKG_CONFIG_PATH must be set. Optionally, if you want to get the cvs repository as a developer, CVS_RSH must also be set.

Open the file /etc/profile (C:\msys\1.0\etc\profile) with your favorite editor (make sure it uses LF line endings) and add:

PKG_CONFIG_PATH="/mingw/lib/pkgconfig"
CVS_RSH=ssh

You might also want to set CFLAGS. Safe options for MinGW are:

CFLAGS="-pipe -O2 -mms-bitfields -march=i686"

just before

export HOME LOGNAME MSYSTEM HISTFILE

and modify that line by adding the four variables:

export HOME LOGNAME MSYSTEM HISTFILE CFLAGS PKG_CONFIG_PATH CVS_RSH

Now restart MSYS. You should now be able to use MSYS without problems.

To install 3rd party library and applications which uses the autotools build system the following commands are often used.

./configure --prefix=/mingw
make
make install

Installing to "/usr/local" should be avoided, "/mingw" should be used instead to avoid conflicts with msysdvlpr.

Building for MSYS

To build an application for MSYS (as opposed to using MSYS), users will need to install msysDVLPR. It contains the headers and libraries to for MSYS along with an old version of GCC and Binutils. Resulting programs will only run under MSYS.

Msysdvlpr should never be treated as a targeted platform. It should also be noted that msysdvlpr is unlikely to be updated in the near future.

MinGW build VS MSYS build

Some programs when used under the MSYS shell can be tricky. One such example is sed.

$ ls *.txt -1 | sed -e s/.exe/\&\!/g

Normally, sed will append "!" to the end of every .txt file, but if sed was compiled and link using MinGW, MSYS will treat it as a native application and will try to change "/" to "\" to compensate for the difference between UNIX path and WIN32, resulting in unpredictability when used under the MSYS shell.

I'm installing MSYS on Win98SE. When running the post-install script, there is a couple of "- Cannot open" errors :

D:\MSYS\postinstall>..\bin\sh.exe pi.sh

This is a post install process that will try to normalize between your MinGW install if any as well as your previous MSYS installs if any. I don't have any traps as aborts will not hurt anything. Do you wish to continue with the post install? [yn ] y

These are known issues. The LF vs. CRLF line ending issue is a packaging bug, which should be addressed fairly quickly, (but I am not the maintainer, and cannot say exactly when he will complete the repackaging exercise). The "cannot open" issue arises because, in fixing another problem, a dependency on a feature which is unsupported in Win9x was introduced. The cause is known, and a work around is under investigation. Please be patient. We will endeavour to continue to support you, but your choice of a now-obsolete operating system makes that more difficult for us, and you will become increasingly prone to this type of issue.

I've just installed the release version 1.0.10 according to the instructions, and things seem to work -- thanks! Without wanting to look ungrateful, I have some comments:

I didn't update bash or coreutils, because there are no links. (Yes, I know I could go and look. I can indeed find some files that look like coreutils, but I'm then not sure what to do with them safely. I would have appreciated step-by-step instructions for the m4 update -- save to c:\msys\1.0, then "bzip2 -d m4-1.4.7-MSYS.tar.bz2" and "tar -xf m4-1.4.7-MSYS.tar". I *am* a newbie.)

I didn't understand the command (../path/to/configure) in the box just after the text "Install them with the 3 with the ..." (text which I also didn't understand). The Enlightenment wiki suggests "./configure" and "make install", and this worked. (I made the edits to C:\msys\1.0\etc\profile before I did this -- I don't know if that helped.)

It would have saved me a *LOT* of time to be told to expect printf not to work unless immediately followed by fflush(stdout);. I had a working system (except for this bug) during several attempts to reinstall, and didn't realise! See https://sourceforge.net/forum/save.php?forum_id=338575.

Also, I seem to have been hit by a restriction of how much memory can be allocated to a fixed-size array in a C program. This may or may not be related to a Vista problem (http://www.trnicely.net/misc/vista.html), though I'm running Window XP. This seems to be cured by using malloc.

When I ran Linux on a 3GHZ machine(debian), I could build red5 and xuggle in a few minutes .
Now I have a 3+GHZ machine running MSYS and MinGW(WINDOWS XP ).It took 10+ hours to compile...(I had add
alias clear=clsb
PKG_CONFIG_PATH="/mingw/lib/pkgconfig"
CVS_RSH=ssh
CFLAGS="-pipe -O2 -mms-bitfields -march=i686"
export HOME LOGNAME MSYSTEM HISTFILE
export HOME LOGNAME MSYSTEM HISTFILE CFLAGS PKG_CONFIG_PATH CVS_RSH

for my MSYS env)
and i found when i use ant for red5 and xuggle it would slowly slowly slowly.....
Can someone help me out here? What am I doing wrong
Any help is appreciated, thanks for reading,

It seems there are trouble with mSys and make.
The mSys make version seems to be 3.79.1, while to build some sources, make 3.80 is required.
The MinGW make is 3.80.
Unfortunately, the MinGW make is a Win32 make, while the mSys make is required to be a POSIX make.
Overwriting mSys make with the executable from the MinGW bin directory obviously does not work.
Running /bin/mingw/mingw32-make instead of make from the mSys console, does not work better.
Is there a location where a make 3.80 for mSys can be found ?

i download and unpack autoconf, automake and libtool in c:
and type in msys : configure --prefix=/mingw && make && make install
but it report error
what can i do to run it?
when i type < ./configure> in msys it reported no such file or directory

You could begin by reading all of the comments below. If you don't find an answer there, then please use the mailing list; (but first, please search the archives, because I've already given definitive instructions for building autoconf, and I'm getting tired of repeating myself).

Please, take this to the mailing list. Better still, search the mailing list archives, because I've answered this already!

In any case, what was the error? You've shown us make's unwind path, but not the actual error diagnostic. Looks like you've tried to configure an `in-source' build. You shouldn't do that! Please read the instructions again. Also, read all of the follow-up comments, particularly the one instructing you not to build `in-source'.

I want to install MSYS in a way similar to that of MinGW, i.e. download separate packages and then integrate them one by one.
The sourceforge repository has a collection of such packages as bash, coreutils, &c., but I don't know how to put them together to make a working copy of MSYS.

Did you try to build it `in place', (i.e. running configure and make in the source directory)?

Short answer: don't do that; use a separate build directory, and run configure specifying the path to the source:

path/to/configure --prefix=/mingw/local ...
make
make install

Alternatively, if you must build `in place', then you must use csmake, (or cpmake), instead of make.

Long answer: autoconf specifies rules to remake the file called `INSTALL', in the top source directory, in addition to the dummy `install' target, to perform the installation. When you invoke make in the top source directory, the presence of the `INSTALL' file, given the case-insensitive property of the MSW file system, conflicts with the `install' rule; `make install' is interpreted as `make INSTALL', resulting in the failure you report. Using a separate build directory seems to resolve the conflict. Using csmake or cpmake subverts the case-retentive property of the MSW file system, to pretend case-insensitive behaviour -- that's an unsafe pretence, in general -- so avoiding the conflict.

I've followed the wiki to install MinGW and MSYS, but I've found that make freezes at random spots in anything I try to build. I've changed to csmake as recommended in the wiki, but the problem remains. Suggestions welcome.

msysDVLPR is only for developing MSYS. The state of the MSYS runtime library is such that it doesn't support some of the newish features that have been developed by Cygwin. Therefore, until someone adds enough features to MSYS, it must use the oldish versions of GCC and binutils.

...if you use only the msysDTK-1.0.1 package, that installs only m4-1.4, which is too old. However, the solution is *not* to go build a native m4 to replace it; you should install the m4-1.4.7 update, which you will find as a separate download, in the same place as the original package:

the directory /usr/bin in Msys is different to the windows subdirectory [Msys/1.0]/usr/bin;

particularly when installing the 1.4.7 M4, it installs to the windows/usr/bin directory, you then need to move it, overwriting the 1.4 M4 in [Msys/1.0]/bin, that is the directory that *Msys* calls /usr/bin [!]