Building with MSVC, PowerShell. Errors

Installation & Configuration Windows
#93

Over on the other place to talk to the devs, Robin gave me the idea of making my own header file that’s force included, so I’ve been editing that.

To my knowledge, no. This has been working fine for me. Currently I have a file that’s 22 lines, combined with a few changes to 3 files in libs/pbd and 4 in libs/pbd/pbd. pbd and wscript diffs (for now) - Pastebin.com

The content of 1.h is currently as follows:

#define _WINSOCKAPI_
#define PATH_MAX _MAX_PATH
#include <sys/timeb.h>
#define NOMINMAX
#include <winsock2.h>

extern "C" inline int gettimeofday(struct timeval *tv, void*) {
    if (tv) {
        struct __timeb64 tb;
        if (!_ftime64_s(&tb)) {
            tv->tv_sec = static_cast<time_t>(tb.time);
            tv->tv_usec = tb.millitm * 1000;
        }
    }
    return 0;
}
#include <io.h>
#define strcasecmp  _stricmp
#define strncasecmp _strnicmp
#define _USE_MATH_DEFINES
#define W_OK 2
typedef intptr_t ssize_t;

Only thing I’m uncertain of is strcasecmp/ strncasecmp.

#94

Thanks Stephen - I’m still not seeing where targetsxs.h gets #included but I guess if you’re happy you don’t need it… :bowing_man:

#95

I have a question regarding your targetsxs.h file: Which lines are vital for compiling libs/tk for you?

#96

It shouldn’t be needed for the tk stuff because that was previously all external to Ardour - but having said that, it won’t be doing any harm.

#97

I’ve figured out how to generate a .def file by modifying the wscript, at least for ydk-pixbuf. I think I’ll be able to use this to make the right .def files. (Well, with a little modification to the .def file, since it seems to give a few extra symbols.)

#98

After a conversation on ardour/github here’s some advice for Stephen / Robin regarding my #defines specified in post #19 above. For the moment I’ll restrict this to the #defines that are definitely needed. Some need to be overall. A few need to be adapted for each project. And some just need to be checked by Robin. Here we go…

Needed ‘per project’ :-

  • BUILDING_PBD // Or its equivalent for the other (non-exe) projects **
  • LIBPBD_DLL_EXPORTS // Or its equivalent for the other (DLL) projects **
  • BUILDING_GETOPT // Only needed when building pbd

** Unfortunately the naming convention for these seems to vary a lot between the different projects. Mostly they can be found in files called visibility.h though even that’s inconsistent. If Stephen can’t figure out some names I should be able to help.

Needed overall (except some aren’t needed for the ‘tk’ builds) :-

  • UINTSDEFINED=1 // I don’t use this for ‘tk’ stuff
  • INCLUDE_ARDOUR_MISCELLANEOUS=1; // I don’t use this for ‘tk’ stuff
  • _SECURE_SCL=0
  • _WIN32
  • _WIN64

These ones are already present overall (but we’d need to check if that still applies for Stephen’s build)

  • PLATFORM_WINDOWS
  • WIN32
  • COMPILER_MSVC
  • NDEBUG // Or DEBUG for a debug build
#99

By chance, did you do these changes on a different branch? Because the last recorded commit I see is ¬3 weeks ago at ardour/msvc_extra_headers/ardourext/sys at master · Ardour/ardour · GitHub .

#100

EZ4Stephen - I’m not familiar with waf so I’m just advising you which changes need to get made. It’ll be up to you and Robin to figure out where to make them.

BTW - when building PBD with MSVC there’s an extra source file (called msvc_pbd.cc) which you’ll need to include in your build.

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