MinGW-w64 for the Uninitiated

2013-10-16

The recent version of MinGW32 fully and totally broke on me this weekend. Actually it broke earlier, I just did not register it. But after SDL2 was unable to load OpenGL on code that worked before the upgrade, the cat was out of the box. All the little issues I had with libraries acting odd are related to something with MinGW's internals being broken; probably something in glibc. (Before someone disses me for this, yes I know the upgrade to GCC 4.7.0 is ABI incompatible, I spent about two days recompiling ALL third party libraries from source.) Finally the MinGW package definition for the installer was updated, but in a broken unusable state, which even ensured that MinGW would not install.

So after some detours I ended up using the MinGW-w64 fork. If you listen to the community, the w64 version is better and more up to date, so that is a plus. The only thing that put me off was the ease of use of getting MinGW32 up and running with the automated installer.

As it turns out it is not that hard to get MinGW-w64 up and running. The only problem is it is not obvious. For that reason I will show you here and now how to get your MinGW-w64 environment in about 5 minutes. (Shorter than it takes you to read this post.)

MinGW-w64

The information on MinGW-w64's website is confusing, partially misleading and for good parts useless. So visit it with caution. I only found out the best course of action after some trial and error.

For the most part we will use the work by the excellent people from MinGW-builds. They provide two ways of getting MinGW, either by installer of 7zip package. Since any developer worth his salt should be able to extract a zip archive, we will use that.

There are multiple build configurations you can choose from.

• The first option is your host system. Unless you are cross compiling (and we will not do that) your host is window.
• Then you have the choice of testing and release. Unless you like to improve GCC or the MinGW compilation you basically want the release version.
• Then you can chose the version, and you basically always want the latest, in my case that is 4.8.1.
• The next option is 32 vs 64 bit, that is the host configuration, not the target configuration. You need to know what your machine is, but in most cases that would be 64bit and that is my case.
• The next option is the thread library used and the options are win32 or posix (pthreads). Without belessing the merits of pthreads, you basically always want to use the native threading library.
• After that you have to chose the exception model. Depending on the "bitness" (32 vs 64 bit) you have the options of dwarf, sjlj or SEH. Following the documentation, you want the chose the model as SEH > sjlj > dwarf. The only thing to note is that you can not mix the models and expect exceptions to seamlessly pass over DLL boundaries. So the choice may be different for your purposes. I will use SEH, which piggybacks on Window's structured exception handling feature.
• Finally files! The last thing to choose is the revision and that is in almost all cases the latest. Here and now this is rev5.

Each of the above options is a folder in MinGW-w64's download folder. I ended up using x64-4.8.1-release-win32-seh-rev5.7z

After downloading the archive you need to unpack it. (You have 7zip, don't you?) I unpacked it under C:\minw64, like the original MinGW. You can put it whereever you like, but historically the packages do not work well with paths with spaces (e.g. "Program Files). This appears to have been resolved, since the installer will put it by default under Program Files.

MSys

For me MinGW and MSys go hand in hand. The primary reason is that configure and make, as used by almost all open source projects simply do not work with cmd.

The MinGW-w64 people do not maintain a MSys fork. The good news is that the MinGW-build people maintain a bundle of the essential development tools, being MSys, 7za, wget, svn, git, mercurial and csv. Wow, what a value!

You can find the bundle under external-binary-packages and here and now the latest version is rev13.

I extracted the archive to c:\msys, but that is up to you.

For MSys some minor adjustments must be made. The first is telling it where everything is by writing an fstab. Like the "real" fstab on a Linux machine, MSys' fstab tells what to "mount" where. My fstab (c:\msys\etc\fstab) looks like this:

c:/mingw64 /mingw
c:/Users   /home    

The minimum you need to do is tell it where mingw is. That will ensure that the compiler is found. I also alias the Win7 user directories into /home. This ensures that user settings are persisted over multiple installs of MSys or other tools like Cygwin or msysGit.

The next thing to do is tell compiler that it should also look into MSys' folder for includes and libraries. From the viewpoint of GCC and friends they are running on a Windows machine and folders like /usr/include simply don't exist so they will not look there. But the behaviour can be regained by specifying the folders in CFLAGS, CXXFLAGS and LDFLAGS. To do this extend the profile (c:\msys\etc\profile) with the following values:

CFLAGS="-I/usr/include -I/usr/local/include -g -Wall"
CXXFLAGS=$(CFLAGS)
LDFLAGS="-L/usr/lib -L/usr/local/lib"

The folders will then be converted by bash to windows paths before handing it off to the compiler.

pkg-config

This is optional, but if you need pkg-config here is how to get it for your MinGW-w64 installation.

The original pkg-config has a very stupid dependency to glib. It is a stupid dependency, since glib also needs pkg-config to build. So if you neither have glib or pkg-config built, you will not be able to build one or the other. (There are ways around this, but it remains a stupid idea.)

Since everybody except the Gnome developers (who invented pkg-config) thought this was a bad idea a fork was created that resolved this dependency: pkg-config-lite.

The only thing they do is take the original pkg-config and package the 4 function from glib into the package. The result is you can build pkg-config without any dependencies.

The best way to get pkg-config-lite is to take the source package. In my cases that is pkg-config-lite-0.28-1.tar.gz.

Building the package is quite standard:

tar -xzvf pkg-config-lite-0.28-1.tar.gz
cd pkg-config-lite-0.28-1
./configure
make
make install

The only thing you need to do is fix the PKG_CONFIG_PATH varaible for proper use in MSys. This is done just like the CFLAGS in the profile:

PKG_CONFIG_PATH="/usr/lib/pkconfig:/usr/local/lib/pkconfig"

Bison and Flex

Not many people need bison and flex, but I do. You may skip this if you do not need flex and bison.

The bad news it that neither bison nor flex work out of the box. Although bison will compile flawlessly, it will stumble when trying to find it's data files. Flex on the other hand will simply not build, by virtue that someone through it a good idea to use fork to implement recursion over analysing lexical expressions.

The good news, somebody else solved the problem for us. That is the Win flex-bison project and you should get the lates version win_flex_bison-2.5.zip.

Although not the cleanest option, what I did was simply extract the contents of the archive to c:\msys\local\bin, including the data directory. (The data directory must be relative to the executables.) By renaming the binaries from win_bision.exe to bision.exe and win_flex.exe to flex.exe every script that expects them, will see them. The only thing I additionally did was move the FlexLexer.h to c:\msys\local\include.