Understanding MSYS / MinGW

MinGW is a port of GCC and the GNU binutils that produces native Win32 binaries.

MSYS is a set of libraries and tools which emulate a Unix-like environment on Win32. MSYS tools are linked with a library that emulates a number of POSIX library calls which do not exist in the Win32 API, and that translates file and directory names to a more Unix-like format. For instance, /c/windows in MSYS corresponds to c:/windows. Because of this, MSYS is very slow, especially when it comes to I/O operations.

The important thing is that the an application built with MinGW is a native Win32 application which does not use the MSYS runtime library and hence does not experience this slowdown. However, this also means that many POSIX library functions are not available.

Microsoft's C runtime library implements a fair subset of POSIX, and MinGW adds some more (much of it as wrappers around Win32 API calls); in practice, well-written application-level code will work fine with minor changes. The real gotchas are the bits that compile just fine but mysteriously fail at runtime, such as fopen(): Windows uses CR LF line endings, so if you fopen() a binary file with r instead of rb, any LF characters read from the file will be expanded to CR LF. The same applies (in reverse) when writing to a file fopen()ed with w instead of wb.

Let's return to MSYS's path translation. It works like this: if an MSYS application (that is, an application linked with the MSYS runtime) calls open() or stat() or unlink() or any other library function that expects a file name, and that file name begins with a /, MSYS will prepend the MSYS root (usually c:/MSYS), unless the first path element is a single letter that corresponds to an existing drive, in which it is interpreted as an absolute path rooted in that drive (as in the /c/windows → c:\windows example above).

Note that so far, I have consistently used forward slashes instead of backward slashes in paths. Here's a dirty little secret: Windows doesn't care what kind of slash you use. You can even mix both in the same file name. Some of the old DOS utilities (such as dir) will assume that anything that starts with a / is a command-line option, but if you steer clear of those, you'll be fine. On the flip side, some MSYS utilities may assume that e.g. c:/windows is a relative path, since it does not begin with a / (which is precisely why path translation is necessary).

This means that whenever these instructions say something like /c/met.no, you can usually substitute c:/met.no with impunity. You can not substitute c:\met.no, or even c:\\met.no, because at some point or other it will end up in an underquoted string on a command line deep in a configure script, and the shell will strip the \.

In fact, sometimes, you must use the Windows form instead of the MSYS form - specifically, when the path will end up in the finished product (either hardcoded into a binary, or somewhere in a compile-time-generated configuration file).

I'd really like to advise you to always use the Windows form, but I won't, since I can't promise that it will always work. What I can promise is that it will work for Metlibs and Diana.