Building Ardour on Windows with MSYS2

NOTE: This post was written for Ardour 4. There is at least one more dependency (liblua, possibly more). Since I wrote this article, I’ve mostly shifted my development environment to linux, hence I haven’t kept this post up to date. So, caveat emptor, YMMV, and other suitable disclaimers. If you just want to use Ardour on Windows, it is now supported on Windows, so why not donate to the Ardour developers and get an official download? I’m currently toying with building Ardour for Windows via the Windows Subsystem for Linux on Windows 10, but a post on that is a bit far away.

Building Ardour on Linux is quick and easy. Building Ardour on Windows…isn’t. That being said, I bashed my way through it, and have come up with a strategy that will get you up and running.

Who is this post for?

This post is most definitely for developers, familiarity with MSYS2 is handy, but as I was basically learning how MSYS2 works as I went, this post won’t assume terribly much on that score. If you just want to use Ardour on Windows I highly recommend downloading a nightly build and using that instead. Keep in mind that Ardour is un-ashamedly built for linux, and it is fantastic on that platform, so if you want the most out of Ardour, use it on linux. If you MUST use windows, know that at present it isn’t supported, and sometimes the nightly builds might be broken. That being said the Ardour developer community is looking into how support could become possible one day.

Other things you might want installed

I find it is handy to have JACK and ASIO4ALL installed.

Getting Started

The first thing you’ll need to do is install MSYS2, but what is MSYS2? Google says this:

MSYS2 is a successor of MSYS and MinGW-builds. 
MSYS2-shell uses “pacman” for downloading packages from
repo, and these are GPG signed & verified. Packages are
by developer: lexx83 (Alexpux), mingwandroid, niXman.

Essentially it is a very light gnu-like environment for Windows, like a very stripped down cygwin. It makes it a lot easier to build linux programs and libraries for windows that don’t use Cmake. There is a good set of instructions here on how to install it and set it up, so I won’t copy them.

Great, now that you’ve followed all the way through that, you should have an up-to-date msys2 system. Now we have a few packages that need to be installed, well, quite a few, most of them from source, but we’ll do it in four batches: tools, prebuilt dependencies, source dependencies, and then some more pre-built packages which require some of our source packages. Before that we should discuss the three shells available to you:

  • MSYS2 shell
  • MinGW-w64 Win64 shell
  • MinGW-w64 Win32 shell

Essentially, the MSYS2 shell is a runtime environment with full posix support. This is most useful for the unix tools. The other two shells have less posix compliance, but play much nicer with the windows APIs, so if you want to build a windows application, you’ll use these. Of these latter two, I’m only using the MinGW-w64 Win64 shell, which uses a 64bit toolchain. That being said, it is easiest of you do all of the package installation (both pre-built, and from source) in the MSYS2 shell. There’s a bunch more detail here.

Install various tools
> pacman -S mingw-w64-x86_64-toolchain python3 \
python3-setuptools mingw-w64-x86_64-python3 \
mingw-w64-x86_64-python3-setuptools python2 \
python2-setuptools pkg-config \
mingw-w64-x86_64-pkg-config autoconf automake perl \
gtk-doc flex bison patch libtool \
mingw-w64-x86_64-libtool wget git nasm \
mingw-w64-x86_64-nasm dos2unix mingw-w64-x86_64-cmake

This will take a while based on your internet connection, etc.

Install pre-built dependencies
> pacman -S mingw-w64-x86_64-glib2 \
mingw-w64-x86_64-gobject-introspection \
mingw-w64-x86_64-pkg-config mingw-w64-x86_64-c-ares \
mingw-w64-x86_64-ca-certificates \
mingw-w64-x86_64-gnutls mingw-w64-x86_64-libidn \
mingw-w64-x86_64-libssh2 mingw-w64-x86_64-rtmpdump \
mingw-w64-x86_64-gnutls libgnutls-devel \
libutil-linux-devel gtk-doc \
mingw-w64_x86_64-docbook-xsl intltool \
mingw-w64-x86_64-libjpeg-turbo \
mingw-w64-x86_64-jbigkit \

Build and install source dependencies

So the thing about MSYS2 is that it stays very “bleeding edge”, whereas most of the Ardour devs use Debian, which has quite a long update cycle. Both approaches have their merit, but they come into conflict when you want to build something that expects debian-ish packages, but have only the most up-to-date packages available. Thankfully, others have blazed this trail before me and have created repositories of package build scripts for most of the packages you’ll need for Ardour. Most of these are quite straight-forward to install, but there are some mighty strange quirks, which we’ll discuss as we get to them.

To get these package scripts, clone my github fork of them:

> git clone

NB: Make sure to switch to the guypkgs branch!

As the README says, to make a given package do the following:

> cd ${package-name}
> makepkg-mingw

And to install it do:

> pacman -U ${package-name}*.pkg.tar.xz

Alternatively, you can do this to build and install at once:

> cd ${package-name}
> makepkg-mingw --install

There are also a few useful flags that you’ll need at times:

--nocheck - disables the 'check' step, which is usually
            unit tests
--nodeps - disables dependency checking, which is 
           useful because a few packages have cyclic 
           runtime dependencies
--skippgpcheck - doesn't check the signature of the 
                 package, I needed this on a couple of
                 packages, only use it if you have 
                 errors relating to unknow public keys,
                 or the pgp part of the process.

So, now that we’ve covered how to build and install the packages, build and install the following list of packages:

 mingw-w64-x86_64-pcre with --nocheck
 mingw-w64-x86_64-gobject-introspection with --nodeps

These should all be straight forward, but some of the will take a long time. Next we get into the weirdest quirk I’ve seen in a while. There are two libraries, harfbuzz and freetype. Turns out they have a circular dependency on eachother. So what you have to do is

First, build and install harfbuzz with –nodeps

> cd mingw-w64-x86_64-harfbuzz
> makepkg-mingw --nodeps --install

This will end up installing the following packages from the pre-built repositories, but the freetype will have no harfbuzz support:


So, next step delete the harfbuzz package that you already built and rebuild it (assuming your still in the harfbuzz directory):

> rm -rf mingw-w64-x86_64-harfbuzz*.pkg.tar.gz
> makepkg-mingw --nodeps --install

Next build and install the following packages:


Ok, now that’s the harfbuzz freetype weirdness out of the way. You should be good to go ahead and install the rest of the source packages:


The second wave of pre-built packages

Ok, so now there are two more pre-built packages that you need to install:

> pacman -S mingw-w64-x86_64-rubberband \
Actually Building Ardour

Ok, so now you have all the dependencies you need to build and run Ardour (although we’ll discuss one other work around a bit later which solved a problem that I had, that I’m not sure if you will encounter or not).

For now you’ll need to clone my fork of Ardour. I’ll update when my pull request is accepted. Get the ardour code (do this from somewhere you’d like the code to go):

> git clone
> git clone git://
> cd ardour

Ardour uses the waf build system. I found there was a tiny quirk with running it under MSYS. Run it as follows to configure Ardour:

> ./waf configure \
  --dist-target=mingw \
  --prefix=/mingw64 \

Then to build it, run

> ./waf

If you want to install it you can do so with

> ./waf install

I’m more interested in running it:

> cd gtk2_ardour
> ./ardev-win

Now, you might find that you get white text on white buttons, like I did, and you’ll probably see warnings about the gtk ‘clearlooks’ engine. I worked out a weird work around for this.

Weird clearlooks workaround

Go to a folder somewhere (ie ~/), and get the gtk-engines source code:

> cd ~/
> wget
> cd gtk-engines-2.20.2
> ./configure \
  --build=x86_64-w64-mingw32 \
  --host=x86_64-w64-mingw32 \
> make
> make install

You’ll get a whole lot of warnings that it can’t find various dlls. That’s no biggie in this case.

Next you’ll want to download a nightly build of ardour for windows and install it.

Then copy C:\Program Files\Ardour4\lib\gtk-2.0\engines\ to C:\msys64\mingw64\lib\gtk-2.0\2.10.0\engines. It’ll want to over-write a file, which is all good. Now if you go back and run Ardour, it should look fine.


It occurred to me after I wrote this that I should have acknowledged all the help the Ardour devs gave me while I was asking pesky questions. They are a very helpful and welcoming group.

Portable C++ on Windows: Part 2 – Libraries

In the previous post in my series on Portable C++ on Windows, Compilers and Command Lines, we walked through the steps required to set yourself up with a windows-based C++ development environment which doesn’t rely on the Microsoft platform. We walked through getting set up with MinGW (GCC for Windows), MinGW-MSYS (BASH for Windows) and more recent versions of the GNU Autotools for your shiny BASH shell.

This time, we will walk through building the Boost libraries and the Xerces C++ XML library. Now, I know I mentioned in the first part that we would cover SFML as well, but this comes pre-built for windows, so we don’t need to worry about that (we will cover installing it and building a small example with it in the next part of this series).


First things first, you need to get hold of the Boost libraries, and also Boost Jam, which is the Boost build system. Use the links below. If you’re from the future you might want to go to and get the latest versions, but at the time of writing the links below were to the latest versions.

I unzipped the Boost JAM archive so that bjam.exe was in c:boostjam, and then used WEVE to edit my PATH environment variable so that the boostjam folder was on it. The next thing you’ll want to do is extract the Boost 1.37.0 archive so that you end up with a folder like c:librariesboost_1_37_0.

Next, fire up MSYS (make sure you are running as an administrator, especially if you are on Vista, with UAC turned on). Change directory to /c/libraries/boost_1_37_0 and then run ./configure. After this has completed you should have a file called user-config.jam. Mine looked like this:

# Boost.Build Configuration
# Automatically generated by Boost configure

# Compiler configuration
using gcc ;

Now open up a windows command prompt (cmd.exe) and navigate to c:librariesboost_1_37_0 and invoke the following commands:

copy user-config.jam toolsbuildv2user-config.jam
bjam debug -toolset=gcc stage

You’ll have to sit and wait for some time, but eventually you’ll have about 4GB of lib and dll files in the stagelib folder.


We’re going to cover building the Xerces 3.0.0 XML library for C++. First, you’ll need to grab the source code and unzip it into the c:libraries folder as well. You should end up with a folder like c:librariesxerces-c-3.0.0. Fire up MSYS again if you closed it, and change directory to /c/libraries/xerces-c-3.0.0 and run:

./configure LDFLAGS=-no-undefined && make && make install

Again, you will have to sit for a while. When everything has completed you should be able to find the Xerces libraries in c:msys1.0locallib unless you installed MinGW-MSYS somewhere else.

That’s all for this part and I hope that everything went smoothly – if it didn’t, drop me a comment and I’ll try to help you out – next time we’ll be covering setting up the Eclipse CDT to use the tools we installed in Part 1, and also how to choose which libraries to link to.

Portable C++ on Windows: Part 1 – Compilers and Command Lines

Danushka and I decided to start a new game engine, and this time portability and simplicity are our two major concerns. The portability is mainly because Danu wants to use linux, and I don’t. Even if we were’t going for portability, we would probably still try to use open tools like Eclipse CDT because the Eclipse platform will allow us to maintain a completely integrated development environment for the engine, including any custom tooling needed for the engine, right through to the end-users of the engine (the game developers).

So, as you may have guessed by now, our tool-chain focusses around the Eclipse CDT (C/C++ Development Tools). In order to use this on windows, you’re going to need a version of gcc, and if you want to build any libraries you’ll probably need a BASH-esque command line replacement. So the tool-chain I am using is this:

  • Eclipse CDT (Gaynemede/3.4)
  • MinGW
  • MinGW-GDB
  • MinGW-MSYS

Also, to facilitate portable development we are using a couple of libraries, namely:

  • Boost
  • SFML
  • Xerces

This first part in my series on “Portable C++ on Windows” will discuss setting up MinGW, MinGW-GDB and MinGW-MSYS. The second part will discuss building Boost, SFML and Xerces, and the third will show you how to put it all together in the Eclipse CDT.

Part 1 – Compilers and Command Lines

These instructions are based on my experiences following these instructions. I am running Vista, and I have hand-picked a combination of the versions of the tools listed below because they worked for me. I also did things slightly differently to the aforementioned instructions because I ran into problems. If you have any problems, drop me a comment and I’ll try get back to ya.

Yout first step should be to download the following (just download them, don’t do anything with them yet):

Ok, step 2: Install MinGW to c:MinGW.  It is a very good idea to install into a path where there are no spaces, MinGW doesn’t really like them. The post install process will run, follow it through, it’s quite straight-forward.

Step 3: Install GDB into the c:MinGW folder. The archive contains a folder structure that is analogous to the c:MinGW folder, so merge the two. gdb.exe should end up in c:MinGWbin.

Step 4 is to install MinGW-MSYS, run the installer, telling it to install in c:msys1.0. This will install version 1.0.10. Extract the update archive (version 1.0.11) into the c:msys1.0 folder. Again the archive’s structure is analogous to the installed structure so the two should merge.

Step 5: Install the msys dtk by running the installer.

Step 6: Install the latest version of m4. Make sure that m4.exe goes into c:msys1.0bin

By now you should have an “M” icon on your desktop. Make sure you always choose to “Run As Administrator” for this if you are on Vista and you’re not a local admin (But don’t run it yet).

Step 7: Extract the automake, autoconf and libtool archives to c:temp (they will each then have their own folder, eg c:tempautomake-1.10 etc…)

Step 8: Run msys as administrator. You are now presented with a unix-esque command line. Directories are mounted so that all of your c-drive contents are under /c, so c:temp would be /c/temp. Change directory into each of the folders extracted in step 7, and run the following:

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

If you have problems building or installing the above, you may not be running as administrator.

Step 9: Get a real text editor, like TextPad, or Notepad++ (or any other one that allows you to choose your line ending type, we want LF endings), and edit C:msys1.0etcprofile. Make the following changes:

Find the line that says:


and replace it with:


Then add the following immediately before the line you just changed:

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

That’s it. Close MSYS and re-open it, and you should be away laughing. Stay tuned for the next part of the series on building Xerces, Boost and SFML (we may not have to build SFML).