The original idea was to document all the steps, from deciding which programming language to use, the books I used to learn, the compiler I decided to use, how to set it up, the editor I would use, its own configuration and so on. There’s quite a lot of stuff and it requires quite a bit of time to examine and figure out.

Since I just went through the process of refreshing a few things, I’ll document at least this transition.

The problem I got was that I was looking for a way to convert hex format color codes, like HTML #FFFFFF, converting it to RGB that I need to use to make colors within libtcod (the roguelike library I use to print stuff on screen).

In the end I came up with something like:
std::stoi(color.substr(1,2),nullptr,16);

This is supposed to work, but in the standard and most up to date version of MinGW it doesn’t:
error: ‘stoi’ is not a member of ‘std’

And if you look it up on the internet you’ll see it’s a bug in the distribution that has been there from YEARS. On top of that, this standard version of MinGW is lagging behind with updates.

So I started looking again for alternatives and found two:
– http://nuwen.net/mingw.html
– http://mingw-w64.sourceforge.net/index.php

I went with the second that seemed more widely adopted but, honestly, the documentation sucks.

“Mingw-builds Project” and “Win-builds Project” on the sidebar lead to the same page. And on that page you find again both options:
Mingw-builds project
Win-builds project

Both seem to target Windows, so I don’t know the difference. I decided to go with the second option that more explicitly targeted Windows and that looked like based on a more stable version. So I end up on another different site:
– http://win-builds.org/index.html

The documentation here is worse than sparse. We get a:
“Installation on Windows can be done for MSYS, Cygwin or without them.”

Initially I tried a barebone install, but eventually I found out there was no “make” in this package, and to compile my own game I normally use a basic form of makefile. MSYS instead is a tool that creates a Linux-like shell under Windows. Normally it is not required, unless you want to compile other stuff that makes also use of Linux commands and the like. This is OFTEN the case when you want to compile other games and libraries.

So I knew that MSYS at least included “make”. But the MinGW package here does not include MSYS. If you follow those instructions on that page you get:
for MSYS: run it from the command-line as: yypkg-1.4.0.exe –deploy –host msys

But if you do this, the program asks WHERE you have installed MSYS. So it’s obvious that first you have to install MSYS, then you install this MinGW on top of it. But, go figure, if you install MSYS it will ask you where you have installed MinGW. So read on and lets figure this out.

Since I needed MSYS, I went looking for a standalone MSYS package, and reached this other page:
– http://sourceforge.net/p/mingw-w64/wiki2/MSYS/

Have I already mentioned the documentation sucks? Because that page there gives you three package options, the last of which is said to be more inclusive. So you go grab that one, but when you look in the archive you notice there’s no “sh /postinstall/pi.sh”, which is exactly the command it tells you do execute to configure the program.

So, instead of downloading that third package, I downloaded the middle one. In this case it had the configuration script. BUT the important point here is that you don’t need to execute that configure command at all. So all those three packages will be fine, and you should just choose them depending on what kind of features you want added (if you are a noob like me you’ll probably use none of them, so you could as well go with the first package. Though, as far this guide is concerned, I personally used the 2nd).

Before starting to install stuff I’ll mention that whereas installing MSYS included with standard MinGW puts MSYS within MinGW itself, instead if you go with the option of installing MSYS, then it’s MinGW that goes into MSYS. So you’ll only interact with MinGW through MSYS itself.

Let’s start installing stuff. Since I work in D:/, I’ll install MSYS in D:/msys.

That second package I downloaded comes in just a “MSYS-20111123.zip”, so I’ll simply unpack it in the directory, making sure that MSYS bin directory becomes d:/msys/bin

At this point you’d normally execute D:/msys/msys.bat opening a Linux/DOS prompt (right click on the window top to set properties as you like, like buffer size, font type and useful QuickEdit mode), so that you could give it the configuration command. But with MinGW-w64 this step should be skipped.

Then I proceed to install MinGW-w64 itself, downloading the package manager from win-builds.org and launching it through the command line/DOS prompt:
yypkg-1.4.0.exe –deploy –host msys

It will ask you to install i686 or x86_64. As far as I know it’s basically 32bit or 64bit. Since I’m on 64 bit I decided to try with 64 by default, and it’s also possible to install both and then switch to the version you want to use through a command given to MSYS. But consider that when I tried to install both, after it finished installing one and started to fetch packages for the other, IT CRASHED. This is not a big deal since you can just relaunch the installer, but it’s a better idea to install 32/64 separately, so running the launcher twice.

After you tell it which version to install, it will ask for MSYS directory, so I give D:/msys which is the root where /bin should be, and press ENTER. Then it will automatically download the packages from the internet and install them.

The whole thing (32+64 bit packages, and MSYS) takes about 1.2Gb on the hard disk.

Now is the time to configure MSYS. Since the package manager seems to install MinGW within MSYS, so that the 32bit and 64bit versions can be freely swapped, there seem to be no need to mess with Windows PATH or MSYS configure scripts.

Instead I used this command (explained here):
echo ‘. /opt/windows_64/bin/win-builds-switch 64’ >> ~/.profile

This essentially switches by default to the 64bit version. Whenever I open msys through the .bat, it will be already set up to work in 64bit toolchain, with all the paths set correctly. If you then type gcc -v it will look up at the right version of gcc it has internally (4.8.2 at this time).

Apparently no other tweak seems needed. I was able to compile my game alright, so the paths should be already set correctly.

In short:
– Install MSYS separately by simply unpacking the archive in a directory you want to use.
– Launch the MinGW package manager through the command: yypkg-1.4.0.exe –deploy –host msys
– Pick either 32bit or 64bit version, or both, and tell it to install into MSYS root directory (where ‘bin’ and other directories are)
– Launch MSYS with the .bat file in its root, and give the command to default to either 32 or 64 version, like: echo ‘. /opt/windows_64/bin/win-builds-switch 64’ >> ~/.profile

Now the problem is that if you want to use 64bit, libtcod library is instead compiled as 32bit version, so if I now try to recompile my game at 64bit it will fail because it says the library is not compatible.

So I went and had to recompile the library itself on 64bit. Yet, this also requires a further step, because the SDL it uses also needs to be in 64bit. Since SDL1 is not available in 64bit, I had to compile it myself. So I downloaded the sources for SDL 1.2.15 (because for some reason SDL2 is INCREDIBLY slow with libtcod), launched through MSYS: configure, and then make.

It compiled alright. Then I only had to move the compiled SDL-1.2.15\build\.libs\libSDL.dll.a to libtcod-svn\dependencies\SDL-1.2.15\lib\mingw

And finally I had to tweak libtcod makefiles, because they use mingw32-gcc and mingw32-g++ that do not exist in this MinGW-w64, so renamed them to just gcc and g++

To compile libtcod I use, from its root: make -f makefiles/makefile-mingw release

Also consider that through my various attempts I was often getting compiler/linker errors. I eventually found out that some data was lingering in C:\Users\username\AppData\Local\Temp\libtcod so make sure the Temp directory is clean if something goes wrong

This should be enough to compile the library fine. The tool to compress the .dll at the end will fail, but the libraries still work well for me.
EDIT: You can obtain here a more recent version of UPX that compresses 64bit files. Just download and move upx.exe to dependencies\upx\win\ in libtcod directory. The makefile will use it automatically, and you can also use it manually to compress SDL dll as well your own game exe, if you want.

So finally, after having both libtcod and SDL compiled in 64bit I could also compile my own game fine. Caveat: it now requires another dll to run: libwinpthread-1.dll, which does not seem to compile statically. So you have to go fish for it in MSYS/MinGW directory and move it to your game dir.

But otherwise it actually runs, and with a nice 8-10% speedup in my case, compared to the usual 32bit version. And std::stoi compiles fine.

Last tweak: D:\msys\etc\profile can be edited so that every time you open msys.bat you are already in the directory you want. At the very bottom there’s a line cd “$HOME”, so I commented that out and edited to what I needed:
cd “D:/foe/foetest”

To update this distribution of MinGW-w64, when new packages are released, go into /msys/opt here there should be one or two directories, for 32 or 64 bits, pick the one you want to update, navigate into, for example, /opt/windows_64/bin and (hopefully) just double click on yypkg.exe it should check the repository for updated stuff and install everything automatically.