Building Ardour on Windows using MSYS2

Hello! I’ve managed to build and run Ardour on Windows using MSYS2 MINGW64. Outside of the errors during ./waf for my specific configure, I do have some uncertainties about what’s right. The Ardour folder is 199 MB, and the msys64 folder is 4.22 GB at the end.

Anyways, first download and install MSYS2. I do it to C:/msys64. Once it’s done, click the hyperlink that opens the folder, then click finish without unchecking the box to run MSYS2. Note that Shift + Insert is the shortcut to pasting there.

You can choose between running multiple commands in one go, or going line by line, or a mix of both. I’ve had some failures when trying to do everything in one go (After the first two pacman -Syu’s), but that may just be a formatting issue for what I had copied, or the download of many dependencies having errors. If you get an errors in the pacman -S code such that it doesn’t install everything, run the same thing again, till it does nothing.


First, run the following:

pacman -Syu

You’ll be prompted twice. Press Enter both times. Then it’ll close, and you’ll have to open mingw64.exe from the folder that clicking the hyperlink opened. Again, Do

pacman -Syu

again. Press enter when prompted. Once it’s done, run the following:

pacman -S --noconfirm --needed git unzip make \
mingw-w64-x86_64-{toolchain,boost,glib2,glibmm,libsndfile,curl,libarchive,liblo,taglib,vamp-plugin-sdk,rubberband,aubio,cairomm,pangomm,jack2,serd,sord,sratom,lilv,libwebsockets,cmake,libusb}

This will take several minutes. Then:

git clone https://github.com/Ardour/ardour.git

I don’t think installing PortAudio with ASIO is necessary, but I did it.

git clone https://github.com/PortAudio/portaudio.git
curl -L -o asiosdk.zip https://www.steinberg.net/asiosdk
unzip -q asiosdk.zip 
cd portaudio 
mv ~/asiosdk_2.3.3_2019-06-14 asiosdk
mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/mingw64 -DPA_USE_ASIO=ON
ninja install

The 2nd last line will take a few minutes. Anyways…

Install FFTW with single precision. I’m not sure if this’ll no longer be required in the future, but it’s needed for now:

cd
curl -LO https://fftw.org/fftw-3.3.10.tar.gz
tar xf fftw-3.3.10.tar.gz && cd fftw-3.3.10
./configure --build=x86_64-pc-msys  --host=x86_64-w64-mingw32  --prefix=/mingw64 --enable-shared --disable-static --enable-float --enable-threads --with-combined-threads --with-our-malloc --enable-sse --enable-sse2 --enable-avx --enable-avx2 --disable-dependency-tracking 
make -j$(nproc)
make install

Then go back to the ardour folder.

cd ~/ardour

What’s left is a little patchwork, then configuring, building and installing. The following works for now, but there may be no need for it in the future:

sed -i '31i\#if !GLIB_CHECK_VERSION(2,32,0)' libs/pbd/pbd.cc
sed -i '33a\#endif' libs/pbd/pbd.cc
sed -i '92i\#if !GLIB_CHECK_VERSION(2,32,0)' libs/pbd/pbd.cc
sed -i '96a\#endif' libs/pbd/pbd.cc
sed -i "s/obj.uselib += \['LILV'\]/obj.uselib += ['LILV', 'SERD', 'SORD', 'SRATOM']/" libs/ardour/wscript
sed -i "/obj.uselib/a\ obj.stlib = ['portaudio']\n obj.lib = ['ole32', 'setupapi', 'uuid', 'winmm', 'ksuser', 'jack64']" libs/backends/portaudio/wscript 
sed -i '264i#if !GLIB_CHECK_VERSION(2,32,0)' gtk2_ardour/main.cc
sed -i '267a#endif' gtk2_ardour/main.cc

Then, configure. do ./waf --help to see what options are available. You might not want to have the same flags as mine. For example, I don’t even have Pro Tools, but I decided to include --ptformat just in case I have to deal with files from it.

./waf configure   --dist-target=mingw   --prefix=/c/Ardour   --configdir=share   --no-execstack   --no-dr-mingw   --optimize   --cxx17   --ptformat

Note: If you have MSVC installed, you’ll have to do the following instead of ./waf configure:

python3 waf configure  --check-c-compiler=gcc  --check-cxx-compiler=g++  --dist-target=mingw   --prefix=/c/Ardour   --configdir=share   --no-execstack   --no-dr-mingw   --optimize   --cxx17   --ptformat

(Add your own configure options after --check-cxx-compiler=g++)

This took me ~8-20 seconds. Unfortunately, I can’t elaborate on everything there. I failed to get lrdf to work with this, so it ended up as follows:

Checking for ‘lrdf’ >= 0.4.0 : not found

Maybe in the future, someone will have a fix for that.

After this, start the build.

./waf -j$(nproc)

(or ./waf build)

This will likely take a long time. The least time that ./waf -j$(nproc) took me was 37m51.973s. (Actually I was doing ./waf build -v 2>&1 | tee build.log in that attempt, so maybe I can do it even quicker… I wonder if having MSVC installed played a role in the speed.)

After that, run ./waf install.

For some reason opening that using file explorer gives 4 errors, but running the following in MSYS2 worked for me: cmd //c "C:\\Ardour\\lib\\ardour9\\ardour-9.0.pre0.1864.exe"
(The .exe file will likely change, but that’s what I currently have)

I have since then Downloaded and installed ASIO4ALL (Download – ASIO4ALL Official Home), which worked for me. If you want to use it, you’ll have to configure it. (I suggest checking Frequently Asked Questions – ASIO4ALL Official Home).

Note that the MSYS2 terminal stops any running command with Ctrl+C. Doing that, or closing the terminal where you did that cmd command, will close Ardour.

image


Below are the most common errors that I faced while running ./waf -j$(nproc), with their solutions. Originally I wanted to post this separately, and make a separate post later for how to build Ardour on Windows, but the error I was stuck on got solved. I assume some of these might get patched in the future. Aside from the errors, there are lots of warnings that’ll pop up in the terminal, but don’t worry about them.


  1. C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: libs/pbd/pbd.cc.1.o:pbd.cc:(.text+0xd1): undefined reference to Glib::thread_supported()' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libs/pbd/pbd.cc.1.o:pbd.cc:(.text+0x1b3): undefined reference to Glib::thread_init(_GThreadFunctions*)’
    collect2.exe: error: ld returned 1 exit status

  2. C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: libs/ardour/globals.cc.1.o:globals.cc:(.text+0x8e28): undefined reference to `fftwf_make_planner_thread_safe’
    collect2.exe: error: ld returned 1 exit status

  3. (Would come with 2nd error, if that isn’t fixed)
    C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: libs/ardour/lv2_plugin.cc.1.o:lv2_plugin.cc:(.text+0x922): undefined reference to __imp_serd_env_free' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libs/ardour/lv2_plugin.cc.1.o:lv2_plugin.cc:(.text+0x827c): undefined reference to __imp_serd_env_new’
    C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: libs/ardour/lv2_plugin.cc.1.o:lv2_plugin.cc:(.text+0x8283): undefined reference to `__imp_serd_env_set_prefix_from_strings’
    collect2.exe: error: ld returned 1 exit status

  4. In file included from …/libs/surfaces/launchpad_pro/interface.cc:26:
    …/libs/surfaces/launchpad_pro/lppro.h:28:10: fatal error: libusb.h: No such file or directory
    28 | #include <libusb.h>
    | ^~~~~~~~~~
    compilation terminated.

  5. C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: libs/backends/portaudio/portaudio_io.cc.1.o:portaudio_io.c:(.text+0xb8c): undefined reference to PaAsio_GetAvailableBufferSizes' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libs/backends/portaudio/portaudio_io.cc.1.o:portaudio_io.c:(.text+0x1e24): undefined reference to PaAsio_GetInputChannelName’
    C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: libs/backends/portaudio/portaudio_io.cc.1.o:portaudio_io.c:(.text+0x1f34): undefined reference to PaAsio_GetOutputChannelName' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: libs/backends/portaudio/portaudio_io.cc.1.o:portaudio_io.c:(.text+0x705): undefined reference to PaAsio_ShowControlPanel’
    collect2.exe: error: ld returned 1 exit status

  6. C:/msys64/mingw64/bin/…/lib/gcc/x86_64-w64-mingw32/15.2.0/…/…/…/…/x86_64-w64-mingw32/bin/ld.exe: gtk2_ardour/main.cc.1.o:main.cc:(.text.startup+0x15d): undefined reference to Glib::thread_supported()' C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/15.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: gtk2_ardour/main.cc.1.o:main.cc:(.text.startup+0x805): undefined reference to Glib::thread_init(_GThreadFunctions*)’
    collect2.exe: error: ld returned 1 exit status


Solutions:

sed -i '31i\#if !GLIB_CHECK_VERSION(2,32,0)' libs/pbd/pbd.cc
sed -i '33a\#endif' libs/pbd/pbd.cc
sed -i '92i\#if !GLIB_CHECK_VERSION(2,32,0)' libs/pbd/pbd.cc
sed -i '96a\#endif' libs/pbd/pbd.cc
pacman -S --noconfirm make 
cd
curl -LO https://fftw.org/fftw-3.3.10.tar.gz
tar xf fftw-3.3.10.tar.gz && cd fftw-3.3.10
./configure --build=x86_64-pc-msys --host=x86_64-w64-mingw32 --prefix=/mingw64 --enable-shared --disable-static --enable-float --enable-threads --with-combined-threads --with-our-malloc --enable-sse --enable-sse2 --enable-avx --enable-avx2 --disable-dependency-tracking
make -j$(nproc)
make install

Then do cd to wherever you have the ardour folder.
I did cd ~/ardour

Note that make -$(nproc) will take a few minutes.

sed -i "s/obj.uselib += \['LILV'\]/obj.uselib += ['LILV', 'SERD', 'SORD', 'SRATOM']/" libs/ardour/wscript

[Rerun the ./waf configure with the tails you used, after this. Then continue with ./waf or ./waf -j$(nproc)]

pacman -S mingw-w64-x86_64-libusb

Then do ./waf configure… again. But, this’ll likely start from the beginning.

sed -i "/obj.uselib/a\ obj.stlib = ['portaudio']\n obj.lib = ['ole32', 'setupapi', 'uuid', 'winmm', 'ksuser', 'jack64']" libs/backends/portaudio/wscript 

[Rerun the ./waf configure with the tails you used, after that sed -i.]


sed -i '264i#if !GLIB_CHECK_VERSION(2,32,0)' gtk2_ardour/main.cc
sed -i '267a#endif' gtk2_ardour/main.cc

3 Likes

Personally I build for Windows but using MSVC, although that’d be difficult for anyone starting off now - mostly because the support libs rarely support MSVC these days :frowning:

How did you get the various support libs for your build, sigc++ / pthread / atkmm etc? Are they already downloadable for MinGW or did you need to build everything yourself?

I decided to install MSVC to see if I could try to do something. This software’s not intuitive to me… I believe you.

Most were available in MinGW, but I had to build FFTW with single precision to overcome one error during the build. I couldn’t make the MinGW version of FFTW work.

I’ll be honest, I don’t recognize these names, sorry. I don’t have the… technical(?) knowledge.

I am curious on what all I’d have to do on MSVC though. Do you have an article or source(s) I can refer to, to try my hand?

Could you elaborate?

Sorry Stephen, I don’t know of anything. AFAIK only 2 people have ever built Ardour successfully using MSVC and I never saw any instructions anywhere. In my case I started off building everything with Cygwin (I think using MinGW) but that was nearly 20 years ago. After I moved to MSVC I probably wrote something down somewhere but I doubt I could find it now - and it would’ve been for a 32-bit build anyway, rather than 64-bit.

Sure - you probably know that MSVC builds things via Solution files (having the extension .sln) and Project files (having the extenstion .vcxproj). In the early days it was almost mandatory for libraries to include both of those files as standard. but over the years, they mostly don’t include tham any more. GTK probably still includes them but the smaller libraries (like FFTW) probably don’t. Nowadays, Ardour probably needs a few dozen of those smaller libraries - but if they no longer provide .sln files and .vcxproj files, it’s near impossible now to build them with MSVC.

[Edit…] Having said that… there’s an app available called CMake which can generate ,vcxproj files if you supply a traditional make file. I’ve tried it once or twice and it worked for me but I don’t think Robin had much success with it. A word of caution though… broadly speaking, stuff built with MinGW and stuff built with MSVC are generally incompatible so you need to build everything with the same compiler. You can’t just build a few modules with MSVC and hope they’ll work :frowning:

I thought almost everything that is required is currently available at https://vcpkg.io/
even rare packages like VAMP-SDK. You can get libsigcpp, [win]pthread there as well, the whole LV2 stack (lilv, serd, sord) (atkmm is no longer required, it’s now part of ardour itself).

Looks like LDRF / raptor are one of the few that are not currently there.

I hate cmake with passion, it’s not just slow (for huge projects like Ardour), but has horrible syntax, and is the only build-system that doesn’t follow established standards.

Yes that’s true, Robin and I think vcpkg was how the other MSVC builder approached it (Andre). The problem was that vcpkg (at least back then) tended to house only the recent versions of libraries and a lot of the versions needed by Ardour weren’t being offered. For example it offered GTK3 and GTK4 but not GTK2, which Ardour uses. I’m not sure how Andre got around that but I think it was a bit kludgy - e.g. building GTK3 and then renaming stuff as if he’d built GTK2 ??

I kinda expected that. Looking forward to doing things from scratch. No promises for now, though.

Ardour does not depend on GTK anymore, the toolkit was internalized 2 years ago, which simplified things significantly.

You do have a point though. One problem of a “too new” package might be glibmm.

I’d re-use as much as possible, and build on existing packages/infrastructure.

On GNU/Linux, getting everything is a one-liner

apt build-dep ardour

and you’re set.

I never understood why most devs prefer OS where things are more complicated than that :wink:

2 Likes

Ah, perhaps “doing things from scratch” was poor choice of words from me.

@EZ4Stephen / @x42 - what would be involved for one of you to build just one of Ardour’s static libs for me, using Clang? I’m thinking possibly fluidsynth? Or maybe the new staffpad lib?

To give some background, I was experimenting with Clang here yesterday and it’s actually quite a good compiler now! In the old days it used to take around 3.5 hours to build just the gtk2_ardour branch but these days they’ve got that down to just 33 minutes, so I’d like to take another look at it sometime - but I’m curious to know if a Clang static lib (built via one of your Windows builds) would be compatible with my MSVC builds.

I do not have a windows system, and our Linux builders which cross compile don’t have a clang setup to x-compile. sorry.

Thanks Robin - and of course if Stephen is already building on Windows, I guess that wouldn’t be a valid test anyway :frowning:

Oh well… back to building with MSVC :slight_smile:

At least for the time being, I’ve turned away from trying to use MSVC after trying to use it for like 3 days on and off. Needing CMakeLists.txt files was where I kinda stopped. Since I don’t know C or C++, it’d take a while for me to make any. If someone were to make a wscript to CMakeLists.txt tool specifically for Ardour (or a generic one that’s highly accurate), that’d be great and I’d try to approach MSVC again. Until then, I’m content with my current build.

You’ve got my attention with asking to build just one static library with Clang though. I’ll see what I can do, but I’m curious on how it’d help you; how it’d be compatible with your build.

[Also speaking of “my current build” at the end of the 1st paragraph, I suppose I should add a paragraph or two of the smallest set of commands to build a newer version of Ardour having already installed all the dependencies and Ardour before. The only way I know is to repeat the git clone, do those sed -i commands, do ./waf configure, build, and install, which will probably take an hour. Not to mention that sometimes the git clone is slow.]

Sorry Stephen, I got a bit mixed up here. I’ve known for a long time that Robin’s current cross-compiled libraries (built using wine and gcc) aren’t compatible with MSVC but I’ve always suspected that if we could build the Support Stack using Clang, it probably would be. Robin does cross-compile and I got it into my head that you were too (which you aren’t - now that I read again). i.e. if you built with Clang, you’d be building on Windows anyway (and I already know that Clang and MSVC are compatible when both are built on Windows…)

I hate cmake with passion, but I won’t start another rant …

Keep in mind that waf can generate MSVC project files [1] and the Ardour wscript does include flags for that [2], which are likely outdated: git blames @John_E adding them in 2014; I don’t know how much work would be involved to get that working.

[1] msvc — Waf 2.1.4 documentation
[2] ardour/wscript at 9ee9e6d139ef9d749e282e54b29387de23db596e · Ardour/ardour · GitHub

I’ve a vague recollection of helping @tnaugle when he was trying to write a waf script for generating MSVC project files but that was a looong time ago! It all got abandoned once the support stack moved to gcc.

And that’s still the main barrier to any MSVC programmer who wants to join Ardour or Mixbus - the gcc/MinGW support libs just aren’t compatible :frowning:

Well yeah, that’s what we’re trying to address here. I am pretty sure that vcpkg.io provides most of it, … and then we can use waf to generate the MSVC project files for Ardour.

If you figure out which libraries are missing at vcpkg we could add those to Ardour’s source-tree, or ask for them to be included at https://github.com/microsoft/vcpkg/issues.

Wasn’t there a programmer called Vance who’d managed to build the support stack using vcpkg and MSVC? Whatever happened to him (maybe invite him to join us here?)

I didn’t realize this earlier, had the wrong idea. I’ll see how far I can go with vcpkg.

Any chance you know why the following error comes?

Checking for function ‘dlopen’ in dlfcn.h : no
The configuration failed

Looking online, it’s not supposed to be a problem for Windows in general, but I’ve not sufficiently understood this problem.

(For reference, I ran the following in PowerShell to get the above: python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat)