Those are just #ifdef's that check if it is defined. I should not be defined anywhere.
Taking a step back: This was the driving factor for me trying to successfully build with MSVC, having already done so with MinGW. But when one installs VS 2026, (since that’s what’s available @ https://visualstudio.microsoft.com/; as it’s no longer Insiders only)
Clang is also an option, unless I’m misinterpreting what I see.
After I installed VS 2026 and restarted, I checked C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\Llvm\x64\bin:
So, is a build with MSVC compiler via waf still sought, or is the option of clang more viable? Or am I somehow supposed to combine both? Sorry if any of you have already explained this before.
@x42 @John_E
Hi Stephen and no, you’re not misinterpreting anything. The good news is that Visual Studio supports building with Clang as well as MSVC - and the even better news is that they seem to be compatible! i.e. you can mix-and-match, building some libraries with Clang and others with MSVC and they all work together (apart from Ardour’s ‘widgets’ branch which doesn’t like being built with Clang for some reason - though I’ve never found time to investigate why…)
In fact Mixbus (and I assume Ardour?) are already build with Clang for the MacOS version so (I assume?) Robin’s already built a MacOS support stack with Clang. What I’ve been suggesting for Windows is that if Robin could find time (and let’s face it - he’s very busy!) he could maybe make a start building his Windows support stack with Clang - just to let us all know how viable it might be. I guess the other possibility is that I could try building it here (initially) although ultimately it’d need to be the stack used by Robin & Paul as that’s the one which tends to get updated.
I think what’s holding it up - apart from Robin’s lack of time - is that the Clang build on MacOS has shown itself to be less efficient than gcc. Up to now though, I haven’t noticed that on Windows. It was less efficient at first but it improved massively. I regularly build Ardour now with Clang.
I sucessfully configured with clang-cl (and then got warnings and errors almost immediately - on a fresh copy of Ardour)
All that’s needed to successfully configure (after getting dependencies) from a fresh copy of Ardour:
& "C:\Program Files\Microsoft Visual Studio\18\Community\Common7\Tools\Launch-VsDevShell.ps1" -Arch amd64
cd C:\dev\ardour
$env:CC = "clang-cl.exe"
$env:CXX = "clang-cl.exe"
$env:PKG_CONFIG_PATH = "C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig"
python waf configure --prefix=C:/Ardour2 --configdir=share --optimize --ptformat --dist-target=msvc --also-include=C:\dev\vcpkg\installed\x64-windows\include,C:\dev\vcpkg\installed\x64-windows\include\sigc++-2.0 --also-libdir=C:\dev\vcpkg\installed\x64-windows\lib --cxx17
Configure output:
Setting top to : C:\dev\ardour
Setting out to : C:\dev\ardour\build
Checking for 'msvc' (C compiler) : clang-cl.exe
Checking for 'msvc' (C++ compiler) : clang-cl.exe
Checking for program 'CL' : C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.50.35717\bin\HostX64\x64\CL.exe
Checking for program 'CL' : clang-cl.exe
Checking for program 'MT' : C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\\x64\MT.exe
Global Configuration
* Install prefix : C:/Ardour2
* Debuggable build : False
* Build documentation : False
Ardour Configuration
* Will build against private GTK dependency stack : no
* Will rely on libintl built into libc : yes
* Will build against private Ardour dependency stack : no
Checking for boost library >= 1.68 : yes
Checking for program 'pkg-config' : C:\Strawberry\perl\bin\pkg-config.bat
Checking for 'glib-2.0' >= 2.28 : yes
Checking for 'gthread-2.0' >= 2.2 : yes
Checking for 'glibmm-2.4' >= 2.32.0 : yes
Checking for 'sndfile' >= 1.0.18 : yes
Checking for 'giomm-2.4' >= 2.2 : yes
Checking for 'libcurl' >= 7.0.0 : yes
Checking for 'libarchive' >= 3.0.0 : yes
Checking for 'liblo' >= 0.26 : yes
Checking for 'taglib' >= 1.9 : yes
Checking for 'vamp-sdk' >= 2.1 : yes
Checking for 'vamp-hostsdk' >= 2.1 : yes
Checking for 'rubberband' : yes
Checking for 'libusb-1.0' >= 1.0.16 : yes
Checking for rubberband >= 3.0.0 : yes
Checking for sndfile RF64=>RIFF support : Found
Checking for int128 support : lots of bits found.
Checking for 'jack' >= 1.9.10 : yes
Checking for clang : yes
Checking for compiler flags ['-std=c++17'] : yes
Warning: you are building Ardour with SSE support even though your system does not support these instructions. (This may not be an error, especially if you are a package maintainer)
Checking for 'fftw3f' : yes
Checking for library setupapi : yes
Checking for 'aubio' >= 0.3.2 : yes
Checking for 'aubio' >= 0.4.0 : yes
Checking for 'gobject-2.0' : yes
Checking for 'gio-2.0' >= 2.2 : yes
Checking for 'libpng' : yes
Checking for header unistd.h : not found
Checking for 'pango' >= 1.20 : yes
Checking for 'cairo' >= 1.12 : yes
Checking for 'pangocairo' : yes
Checking for 'gio-windows-2.0' : yes
Checking for header unistd.h : not found
Checking for 'gmodule-2.0' : yes
Checking for header unistd.h : not found
Checking for 'sigc++-2.0' >= 2.0 : yes
Checking for 'cairomm-1.0' >= 1.8.4 : yes
Checking for 'pangomm-1.4' >= 1.4 : yes
Checking for 'lv2' >= 1.16.0 : yes
Checking for 'libxml-2.0' : yes
Checking for header execinfo.h : not found
Checking for header unistd.h : not found
Checking for function 'posix_memalign' in stdlib.h : no
Checking for function 'getmntent' in mntent.h : no
Checking for function 'localtime_r' in time.h : no
Checking for library ole32 : yes
Checking for 'cppunit' >= 1.12.0 : not found
Checking for header cwiid.h : not found
You are missing the cwiid headers needed to compile wiimote support
Checking for 'libwebsockets' >= 2.0.0 : yes
Checking for 'jack' >= 1.9.10 : yes
Checking for JACK metadata API : ok
Checking for jack_port_rename() : ok
Checking for 'portaudio-2.0' >= 19 : yes
Checking for header pa_asio.h : not found
Checking for program 'gas, gcc' : C:\Strawberry\c\bin\gcc.exe
Checking for program 'ar' : C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.50.35717\bin\HostX64\x64\LIB.exe
Checking for 'lrdf' >= 0.4.0 : not found
Checking for 'samplerate' >= 0.1.0 : yes
Checking for 'lv2' >= 1.2.0 : yes
Checking for 'lv2' >= 1.10.0 : yes
Checking for 'lv2' >= 1.17.2 : yes
Checking for 'lv2' >= 1.18.6 : yes
Checking for 'serd-0' >= 0.14.0 : yes
Checking for 'sord-0' >= 0.8.0 : yes
Checking for 'sratom-0' >= 0.2.0 : yes
Checking for 'lilv-0' >= 0.24.2 : yes
Checking for 'ogg' >= 1.1.2 : yes
Checking for 'flac' >= 1.2.1 : yes
Checking for 'fftw3f' >= 3.3.5 : yes
Checking for header sys/vfs.h : not found
Checking for header sys/statvfs.h : not found
Checking for header unistd.h : not found
Checking for 'ioprio_set' syscall support : no
Checking for header boost/ptr_container/ptr_list.hpp : yes
Checking for library gdi32 : yes
Checking for 'samplerate' >= 0.1.7 : yes
Checking for 'lv2' >= 1.0.0 : yes
Checking for 'cairo' >= 1.12.0 : yes
Checking for 'gthread-2.0' >= 2.10.1 : yes
Checking for 'x11' >= 1.1 : not found
Checking for 'pangoft2' >= 1.36.8 : yes
Checking for 'fontconfig' : yes
Checking for header stdio.h readline/readline.h : not found
* build session-utils : yes
Checking for library gdi32 : yes
* Build documentation : False
* Debuggable build : False
* Export all symbols (backtrace) : False
* Install prefix : C:/Ardour2
* Strict compiler flags : []
* Internal Shared Libraries : True
* Use External Libraries : False
* Library exports hidden : True
* Free/Demo copy : False
* ALSA DBus Reservation : False
* Architecture flags : None
* ARM NEON support : False
* Aubio : True
* AudioUnits : False
* Build target : msvc
* Canvas Test UI : False
* Beatbox test app : False
* CoreAudio : False
* Debug RT allocations : False
* Debug Symbols : False
* Denormal exceptions : False
* Dr. Mingw : False
* FLAC : True
* FPU optimization : True
* FPU AVX512F support : False
* FPU AVX/FMA support : False
* Futex Semaphore : False
* Freedesktop files : False
* G_ENABLE_DEBUG : False
* I/O Priority Set : False
* Libjack linking : link
* Libjack metadata : True
* Lua Binding Doc : False
* Lua Commandline Tool : False
* LV2 UI embedding : True
* LV2 support : True
* LV2 extensions : True
* LXVST support : False
* Mac VST support : False
* NI-Maschine : False
* OGG : True
* Phone home : True
* Program name : Ardour
* Samplerate : True
* PT format : True
* PTW32 Semaphore : False
* Threaded WaveViews : True
* Translation : True
* Unit tests : False
* Use LLD linker : False
* VST3 support : True
* Windows VST support : True
* Wiimote support : False
* Windows key : Mod4><Super
* PortAudio Backend : True
* CoreAudio/Midi Backend : False
* ALSA Backend : False
* Dummy backend : True
* JACK Backend : True
* PulseAudio Backend : False
* Buildstack : -system-
* Mac i386 Architecture : False
* Mac ppc Architecture : False
* Mac arm64 Architecture : False
* C compiler flags : ['-IC:\\dev\\ardour', '/nologo', '/nologo', '/nologo', '-DHAVE_RF64_RIFF', '-DPLATFORM_WINDOWS', '-DCOMPILER_MSVC', '-DUSE_CAIRO_IMAGE_SURFACE', '-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', '-pipe', '-DARCH_X86', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-Wno-deprecated-declarations', '-DBOOST_SYSTEM_NO_DEPRECATED', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="9"', '-Wstrict-prototypes', '-Wmissing-prototypes', '-D_POSIX_C_SOURCE=200809L']
* C++ compiler flags : ['-IC:\\dev\\ardour', '/nologo', '/nologo', '/nologo', '-DHAVE_RF64_RIFF', '-DPLATFORM_WINDOWS', '-DCOMPILER_MSVC', '-DUSE_CAIRO_IMAGE_SURFACE', '-DCOMPILER_INT128_SUPPORT', '-DWAF_BUILD', '-DNDEBUG', '-fshow-column', '-O3', '-fomit-frame-pointer', '-ffast-math', '-pipe', '-DARCH_X86', '-Wall', '-Wpointer-arith', '-Wcast-qual', '-Wcast-align', '-Wno-unused-parameter', '-Wno-deprecated-declarations', '-DBOOST_SYSTEM_NO_DEPRECATED', '-D_ISOC9X_SOURCE', '-D_LARGEFILE64_SOURCE', '-D_FILE_OFFSET_BITS=64', '-DPROGRAM_NAME="Ardour"', '-DPROGRAM_VERSION="9"', '-std=c++17', '-DBOOST_NO_AUTO_PTR', '-Woverloaded-virtual', '-Wno-mismatched-tags', '-Wno-cast-align', '-Wno-unused-local-typedefs', '-Wunneeded-internal-declaration', '-D__STDC_LIMIT_MACROS', '-D__STDC_FORMAT_MACROS', '-DCANVAS_DEBUG', '-DBOOST_ERROR_CODE_HEADER_ONLY']
* Linker flags : ['/nologo', '/MANIFEST', '/nologo', '/MANIFEST', '/nologo', '/MANIFEST']
'configure' finished successfully (34.021s)
Note that I didn’t have to use $env:AS = … because I had installed Strawberry ages ago to install one of those 4 dependencies, which apparently has gas to pass that gas/gcc check. Also: I didn’t edit the wscript at all.
So: Should clang/clang++ be used instead, or a combo of --dist-target=msvc and clang-cl? clang-cl uses MSVC’s flags, based on what I’ve read online.
And should we start a new Post on the forum? I was thinking something like “Building with Clang (From VS 2026) on Windows”, if so.
Stephen - you won’t have any more success building with Clang or with MSVC. The basic problem is that the support libs from vcpkg aren’t the same ones needed by Ardour. Either they’re the wrong version or they’re using different names from the expected ones - or both! (see my posts '#102 and #108)
The compiler is completely orthogonal to the issue at hand, you could also use Intel’s ISC, or Borland bcc64, or really any C++ compiler that understands C++17.
The goal of not using mingw is to attract Windows devs, most of which use Visual Studio, and the IDE with included debugger.
As for the way to get there,… waf would be one way. If you can get PowerShell + waf + vcpkg.io working, I expect it’d be a small step for someone else to also use the Visual Studio IDE.
@John_E How do you deal with #include “libpbd-config.h” (and 3 others that are similar)? Since those are created by the wscripts, and you build without waf.
I must admit, I don’t know… I couldn’t find any similar ones but I do have libpbd-config.h here. However, it dates back to 2013 so I can’t remember where it came from (maybe at one time it was a standard part of the git files??)
Is libs/pbd/debug_rt_alloc.c (and its header) just for your build?
No. AFAICT it’s only used by the non-MSVC builds, whenever DEBUG_RT_ALLOC is #defined (so presumably, only for Debug builds).
I might make a separate post in the future about it, but I’ve switched to using a python script with Python 3.14 and Jinja2 3.1.6 to create MSBuild files for the past several days. Maybe I’ll elaborate, maybe not.
@John_E When building luabindings (which is in libs/ardour), one of the files included from one of the files that are included (or eventually included) is libs/evoral/evoral/note.h.
Note.h has 2 sections addressing COMPILER_MSVC alone:
#ifdef COMPILER_MSVC
class LIBEVORAL_LOCAL Note {
#else
class LIBEVORAL_TEMPLATE_API Note {
#endif
#ifdef COMPILER_MSVC
#include "../src/Note.impl"
#endif
I don’t see this Note.impl anywhere, and am getting an error because of it.
Do you have the .impl file? What are its contents? Can the inclusion of that be replaced with some code, or can it be deleted altogether? And by chance, could you explain the need for that if/else in the first block?
Basically it’s an exact copy of libs/evoral/Note.cc. It’s needed because MSVC doesn’t consider template functions to be exportable from a DLL. You need to implement them somewhere if they’ll be used outside of libevoral. Here are the steps you’ll need to take:-
- When building evoral (before starting the compilation) add some code which copies libs/evoral/Note.cc to libs/evoral/src/Note.impl
- Add something to ensure you don’t compile Note.cc when building with MSVC. I’d imagine it might look something like this in libs/evoral/wscript (or whatever the perl equivalent would be, of course):-
ControlSet.cc
Curve.cc
Event.cc
#ifndef _MSC_VER
Note.cc
#endif
SMF.cc
Sequence.cc
debug.cc
Hope that helps… BTW I’ve been trying to find out from Microsoft if they ever included the glib stuff (at version 2) in any of their previous vcpkg tags but they’re totally ignoring me (which I assume means they didnt!)
This is crazy! 
Why copy it instead if using it directly is possible?
Is this template issue still present with recent MSVC? We use templated API just fine in other places.
I guess you could change Note.h and add a line saying #include “…/Note.cc” but IMHO, that would make it look like there’s a circular dependency. To me, #including Note.impl makes it a bit clearer we’re #including something for the purpose of ensuring something gets implemented.
Yes, it’s still present in VS2022
1 Like
Sorry if I’m missing something obvious but doesn’t this forum allow users to be contacted via a private message?
It is a public forum. There are no private messages.
Groan… in that case, @EZ4Stephen - please will you stop introducing changes that break my build! Yesterday’s commit #98b9839e58 prevents libpbd from linking here. Whether built with MSVC or Clang, both compilers complain now about multiply defined symbols.
I’ve mentioned previously that the existing code is already buildable with MSVC whereas the support libs from vcpkg are known to not work properly with Ardour. And while I’ve no problem if you prefer finding stuff out the hard way, please make sure you protect code that’s already working (e.g. maybe surround your additions with #ifdef WAF_BUILD and else)
I committed those changes, so blame me…
Replace DECLARE_DEFAULT_COMPARISONS · Ardour/ardour@98b9839 · GitHub is just the inline version of what -DECLARE_DEFAULT_COMPARISONS did.
Could you explain why you have introduced that indirection in the first place. The new code is much cleaner.
What is the actual error message that you get?
Not really. It depend on non-standard headers, which have to copied and renamed to be used. The goal here is to avoid that and use standard headers only.
We try to not break existing builds, here by using WAF_BUILD defines to distinguish them.
Here’s a screenshot after trying to link (with Clang). It’s not massively helpful but neither is MSVC’s 
To be honest, it doesn’t look like an idea I would’ve come up with myself so it was probably suggested by Todd (or Ben?)
Either way, I’ll stay out of this thread from now on - except to repeat that if we end up with code that won’t build any more with MSVC (which looks increasingly likely…) I won’t be stepping forward to fix it…
I see now. LIBPBD_DLL is never defined [1]. so the correct expansion of DEFAULT_COMPARISONS_DEFINED is
#define DECLARE_DEFAULT_COMPARISONS(Type) \
extern bool operator > (const Type& lhs, const Type& rhs); \
extern bool operator < (const Type& lhs, const Type& rhs); \
extern bool operator != (const Type& lhs, const Type& rhs); \
extern bool operator == (const Type& lhs, const Type& rhs);
#endif
the extern was lost.
Also libs/pbd/pbd/abstract_ui.inc.cc still uses DECLARE_DEFAULT_COMPARISONS which may explain the duplicate conflicting declatations.
[1] libs/pbd/pbd/msvc_pbd.h would define it when statically building libpbd.