Building with MSVC, PowerShell. Errors

Installation & Configuration Windows
#101

I’ve managed to link pbd.dll without needing msvc_pbd.cc. So I’m unsure if I actually need to define BUILDING_GETOPT.
C:\dev\ardour\build\libs\ardour\ardour.dll : fatal error LNK1120: 1320 unresolved externals…

I’ve added many things from targetsxs.h, but do I actually need #include <gtkmmconfig.h>?

Those are usually there by default in the different wscripts, I believe.

image
image788×189 6.6 KB

Pictured: part of libs/pbd’s wscript, as an example.
image
image976×82 5.33 KB

Pictured: part of the root wscript.

Can you explain this one with an example?

On a sidenote, I’m still inclined to think that the files being made as .o instead of .obj are the cause of linking errors. But I got no proof. Or haven’t got a good solution.

1 Like
#102

The most likely explanation is that the builds in vcpkg are using different names from the names that Robin uses. For example, when building libsamplerate, vcpkg seems to produce a DLL called samplerate.dll whereas Robin’s one is called libsamplerate-0.dll

But I still don’t understand why you always want to leave things out of your own build. What do you think you’ll gain from that?

#103

My reasoning is that ardour builds normally on other systems, and there’s probably a limit of how many extra files are needed for MSVC. I also assume that ideally, nothing specific is needed aside from the force-included headers.

#104

I must admit I’m curious to know how you managed to link libpbd. AFAICT it also needs support libs whose names are different when built from vcpkg - e.g. pthread / sigc++ etc (or maybe Robin builds them as static libs??)

#105

Aside from editing like 7 files from libs/pbd and libs/pbd combined, and added the following around line 1260 of the root wscript.

        conf.env.append_value('LIB', 'pthreadVC3')
        conf.env.append_value('LIB', 'ws2_32')
        conf.env.append_value('LIB', 'winmm')
        conf.env.append_value('LIB', 'advapi32')
        conf.env.append_value('LIB', 'shell32')
        conf.env.append_value('LIB', 'user32')
        conf.env.append_value('LIB', 'dbghelp')
#106

I’ve spent most of today investigating this. In theory yes, it’s needed but of course #include <gtkmmconfig.h> now needs to say #include <ytkmmconfig.h>. Strangely though, when I changed it here, gtkmm itself refused to link, showing me lots of missing symbols. It almost looked like something thought that GTKMM_DISABLE_DEPRECATED was #defined but I can’t see it defined anywhere.

So if you’d prefer to comment out that line temporarily I’ll carry on investigating (not confident I’ll find the problem though…)

#107

Looks like it’s already included in the files where they’re needed? I assume you have a file named gtkmmconfig.h somewhere that gets included for you, else you’d have errors when building.

I assume you already know ytkmmconfig.h is in ardour\libs\tk\ytkmm\ytkmm.

Currently I assume this scope of investigation either leads to nothing, or leads to more differences observable between your (MSVC) build and the existing build.

Meanwhile I feel like I’ve hit a roadblock on solving the unresolved externals, and I should probably make a .def file by running dumpbin on the .o files in build/libs/ardour.

My only ‘leads’ are that luabindings is built as a static library whereas libardour is a shared library by default, and that I might have to use /WHOLEARCHIVE somewhere, somehow. (But then, my object files are .o instead of .obj so maybe it won’t work?)

#108

You’ve made a valiant effort Stephen but in the end, you’ve proved what I said right at the start… if the main devs want to attract new developers, they’ll need to provide a known working support stack. Expecting newcomers to build against arbitrary support libs, where the libs and DLLs are constantly changing - and don’t even have the right names! - it just ain’t gonna work :-1:

#109

Those are just #ifdef's that check if it is defined. I should not be defined anywhere.

#110

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.

image
image395×552 11.9 KB

After I installed VS 2026 and restarted, I checked C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\Llvm\x64\bin:

image
image1684×310 15.5 KB

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

#111

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.

#112

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.

#113

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)

#114

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.

#115

@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.

#116

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??)

#117

Is libs/pbd/debug_rt_alloc.c (and its header) just for your build?

#118

No. AFAICT it’s only used by the non-MSVC builds, whenever DEBUG_RT_ALLOC is #defined (so presumably, only for Debug builds).