Building with MSVC, PowerShell. Errors

EZ4Stephen · December 22, 2025, 10:52am

I’m at 1842/1842 now, everything else is done.

[1842/1842] Processing ardour.keys: gtk2_ardour\ardour.keys.in gtk2_ardour\mixer.bindings gtk2_ardour\processor_box.bindings gtk2_ardour\step_editing.bindings gtk2_ardour\monitor.bindings gtk2_ardour\trigger.bindings gtk2_ardour\regionfx_box.bindings gtk2_ardour\automation.bindings → build\gtk2_ardour\ardour.keys
‘perl’ is not recognized as an internal or external command,
operable program or batch file.

Considering making a custom python script for msvc.

Edit: Made one. ‘build’ finished successfully. Now I gotta install or something.

Another edit: ‘install’ finished successfully (39.056s)
Now I figure out how to correctly run it, because clicking the .exe’s gives me 4 “random” .dll errors, similar to my first post ~3.5 months ago.

More specifically: I get pthreadVC3.dll was not found, fontconfig-1.dll was not found, getopt.dll was not found, glib-2.0-0.dll was not found.
Do they have a common problem? Me using --also-libdir? I assume --also-include has nothing to do with this. Trying to open it via cmd using a powershell command (cmd /c “C:\Ardour2\lib\ardour9\ardour-9.0.rc1.14.exe”) isn’t working either.

EZ4Stephen · December 22, 2025, 11:37am

I ran $env:PATH = "C:\dev\vcpkg\installed\x64-windows\bin;$env:PATH", followed by the above command again. Got none of the missing .dll errors, but the app didn’t start. So including the bin folder seems to be a right step, but I need to do more.
(Also the resulting folder is 1.28 GB)

EZ4Stephen · December 22, 2025, 12:44pm

Copied ALL dll’s in C:\dev\vcpkg\installed\x64-windows\bin to C:\Ardour2\lib\ardour9, now there’s no error when clicking the .exe, but all it does is open a command prompt terminal for like 1.5 seconds and close.

John_E · December 22, 2025, 1:46pm

It might just be a case of DLL’s and EXE’s not being in the folders where Ardour is expecting to find them (usually in a folder with the name bin). For example, your main Ardour exe is in a folder called C:\Ardour2\lib\ardour9 (and the same probably applies to your DLL files) whereas Ardour itself would install them somewhere like C:\Program Files\Ardour9\bin

Another important point is that you shouldn’t reference the files directly from your vcpkg folders (because ordinary users won’t have those folders). You need to copy them to wherever Ardour expects to find them.

And yet another important point is that Ardour needs lots of other files (such as .mid files / .ttf files etc). I don’t know if waf installs all that stuff for you but if not, you probably just haven’t got them installed anywhere.

Your best bet might be to install an official build of Ardour and study it to figure out which files need to go where. Re-create the folder structure somewhere else and copy across any files which aren’t files you built yourself. Then copy your own EXE’S and DLL’S to wherever they need to go. Good luck with it all…

EZ4Stephen · December 23, 2025, 11:59am

@John_E What is RDC_BUILD? I assume you use the macro in your builds, but what does it stand for and how do you use it?

John_E · December 23, 2025, 12:11pm

You don’t need to worry about it. For my builds I actually build 3 x targets:- 1) a Debug build, 2) a Release build, and 3) A Debuggable Release build.

As long as you don’t #define RDC_BUILD it shouldn’t cause any problems.

EZ4Stephen · December 23, 2025, 12:43pm

I changed some things in main.cc, also changed some things in 2 or 3 wscripts to replace the \ with /:

        'DATA_DIR="'   + os.path.normpath(bld.env['DATADIR']).replace('\\', '/') + '"',
        'CONFIG_DIR="' + os.path.normpath(bld.env['SYSCONFDIR']).replace('\\', '/') + '"',
        'LOCALEDIR="'  + os.path.join(os.path.normpath(bld.env['DATADIR']), 'locale').replace('\\', '/') + '"',

Then built and installed. The .exe went back to its (probably normal) size ~10k kb instead of ~600 kb, but it gave errors. (Note: I had deleted the contents of Ardour2 earlier so the .dll’s weren’t copied.)

Recopied the .dlls, the .exe opened the following:

I assume I might’ve had problems due to ardour_main instead of main, from the original version of main.cc. Also Added a little snippet of something for MSVC, though I’ll ignore that for now.

But it acts a little more normal!

Strangely, Dummy backend is missing. I suppose that can wait for later.

I recall that when configuring, pa_asio.h wasn’t found, so maybe that’s why I don’t have the ASIO option from downloading ASIO4ALL from my MinGW build.

Edit: looks like it crashed on the “Indexing Plugins” screen. So something relating to (I assume the vst scanners) needs to be edited.

EZ4Stephen · December 23, 2025, 1:10pm

Running "C:\Ardour2\lib\ardour9\ardour-9.0.rc1.14.exe" | more in command prompt, it says the following among other things:

Ardour: [WARNING]: VST scanner app (ardour-vst-scanner) not found in path C:\Ardour2\lib\ardour9\fst;C:\Ardour2\bin
Ardour: [WARNING]: VST3 scanner app (ardour-vst3-scanner) not found in path C:\Ardour2\lib\ardour9\fst;C:\Ardour2\bin

Which files/folders to check, which could be responsible for these?

John_E · December 23, 2025, 1:23pm

Looks good! - but like I said in post #164, you should check the file layout as used by an official Ardour install and figure out how to copy your own DLLs and EXE’s into the correct folders.

Though of course if waf is supposed to handle that already, @paul or @x42 will need to help you figure out why that isn’t heppening…

John_E · December 23, 2025, 5:12pm

Another bit of good news regarding one of my earlier posts…

In the early days (with the exception of misc.h) all those headers were available when building with MinGW but not when bulding with MSVC. But I just looked at vcpkg and the missing ones have all become available now when building the support stack with vcpkg. So their corresponding .input files won’t be needed now if someone builds their support stack using vcpkg.

EZ4Stephen · December 26, 2025, 7:12am

I decided to finally get perl and use the original fmt-bindings script. I’ve gone a little farther, but got a new error about “panners”:

Edit: I assume the likely cause of the error is in libs/panner_manager.cc, and I have to make an edit such that it skips the first #if when WAF_BUILD is defined.

EZ4Stephen · December 26, 2025, 7:46am

It works! At least the very little functions of adding a midi track and a few notes. Now I gotta submit pull requests for things like gtk2_ardour, liblua, headless, session_utils and more.

EZ4Stephen · January 6, 2026, 9:36am

Done with the first round of pull requests. Once they’re merged, I’ll try building with a fresh copy of unmodified source files, see how it goes and probably make a 2nd round of few requests.

Meanwhile: I briefly explored trying to get the elusive, older versions of libsigcpp/glibmm/pangomm/cairomm, using a vcpkg.json and vcpkg-configuration.json. If I can get them all successfully, I can easily get the other dependencies too, which don’t give problems.

John_E · January 6, 2026, 10:25am

Thanks Stephen and happy new year! Out of interest, what happens when you build against the newer versions of those libraries? Does the code build but then give runtime problems? I think that’s what Andre saw…

EZ4Stephen · January 6, 2026, 10:32am

I’m pretty sure it’s just different APIs or something like that. I remember I was trying to build with the newer libs at first. Maybe I documented some of the errors in an older forum post (Perhaps the one on building with MSYS2’s MinGW?) But I’m not considering going looking for it.

For example, latest glibmm doesn’t have helperlists or threads, if I’m not mistaken, but Ardour (currently) uses them.

Happy new year to you too.

Also to sate any further curiosity, here’s the current versions of the vcpkg files I’ve made. Note that you just go to the directory, run vcpkg install (without naming the libs) and it installs based on the .json files.
vcpkg.json:

{
  "dependencies": [
    {
      "name": "pangomm",
      "version>=": "2.40.1"
    }
  ],
  "overrides": [
    {
      "name": "pangomm",
      "version": "2.40.1#4"
    },
    {
      "name": "bzip2",
      "version": "1.0.8#2"
    },
    {
      "name": "glib",
      "version": "2.52.3#27"
    },
    {
      "name": "pixman",
      "version": "0.38.4#2"
    },
    {
      "name": "cairo",
      "version": "1.16.0-5#0"
    },
    {
      "name": "fontconfig",
      "version": "2.13.1#3"
    }
  ]
}

vcpkg-configuration.json:

{
  "default-registry": {
    "kind": "git",
    "baseline": "640c439df78158904992c51fcbc46f64da113690",
    "repository": "https://github.com/microsoft/vcpkg"
  },
  "registries": [
    {
      "kind": "artifact",
      "location": "https://github.com/microsoft/vcpkg-ce-catalog/archive/refs/heads/main.zip",
      "name": "microsoft"
    }
  ]
}

Edit: Forgot to mention, I get errors when it gets to installing cairo, with the above two files.

Now I wonder if the configuration file can use a different repository than microsoft’s vcpkg. If it can, maybe I can make a repository just for the deps for Ardour or something like that, and if it works, Ardour can copy it and have its own repository. But I’m getting ahead of myself by saying this. Surely if vcpkg’s own repository works, perhaps nothing else is needed.

John_E · January 31, 2026, 9:57am

Just wondering… what was the outcome of all this?

EZ4Stephen · February 2, 2026, 4:58am

For better or worse, I failed to get the vcpkg manifest to work how I wanted it to. Since late yesterday, I’ve looked into alternatives to vcpkg and Conan 2.0 is an option. Given it’s not by Microsoft, I have more faith in trying to use that. Likely won’t need to make another repo, just additional files. (At least a conanfile.py to start with. I’m currently trying to get some packages independently without trying to configure Ardour. Next step will be configure once things work.)

John_E · February 2, 2026, 9:54am

Would it be worth us agreeing on a naming standard for the built libraries? For example… when I first built my 64-bit modules, the 32-bit builds were still in common usage. So I differentiated my 64-bit DLL’s by adding 64 to their name. As an example, my glib modules are called libglib64-2.0-0.dll and libglib64-2.0-0.lib

It could be argued that that’s not necessary these days and it wouldn’t be hard to remove the 64 - but I also like to differentiate debug builds by adding a D - e.g. the new one would be libglib-2.0-0D.dll and I must admit, that’s something I’d like to keep. I noticed that vcpkg gives identical names to both its Debug builds and Release builds - which generates a big risk that people will accidentally mix up Debug modules and Release modules.

EZ4Stephen · February 3, 2026, 9:15am

In some regards, I agree. I haven’t thought about the 32/64 bit aspect, but I have considered the adding d for debug aspect.

So far, I’m yet to build any Debug libraries in Conan. BUT, in the example of vcpkg, the pthreadVC3 libs were named differently for the debug and release builds.

Line 1270 (for now) of Ardour’s wscript has pthreadVC3. https://github.com/Ardour/ardour/blob/master/wscript

I remember when trying to switch to debug build and pointing to the debug lib folder, it wasn’t found. It needed pthreadVC3d instead. So in some regard, I’ve been intending on making an update post along the lines of “Ardour built with MSVC via waf: Update” (after 9.0’s out and I build with source files that contain the edits in my pull request), where I’d mention the lib name mismatches as an aspect needing more modifications, among other things I’ve thought of. [E.g. for “other things”: the bundle files, or dlls needing to be copied - I still have to make a script or look into ARDOUR_DLL_PATH, and the fact that release builds would likely be buildable (Implying I’d also need to have/share/improve a clear recipe for getting the deps) but uncertain about debug]

Image showing some pthread libs (Release build) - vcpkg

Image showing some pthread libs (Debug build) - vcpkg

(Also in case my reply isn’t clear, the “agreement” part is about the naming of the libs itself, not merely dealing with the existing name mismatches)

John_E · February 3, 2026, 10:46am

Good point! I suppose if Paul and Robin don’t add D to their debug libraries it needs a bit more thought… in fact I’ve often wondered if Robin links his Debug builds against his Release build for the support stack?? (because Robin’s Debug builds perform an awful lot better than mine!) One drawback would be if it introduced a need to differentiate between the official waf builds and your additions, which is likely to get complicated

But to stay with Glib as an example:- for my MSVC builds, the link lib for Glib (release) is called libglib64-2.0-0.lib and has 389,396 bytes. Glib (Debug) is called libglib64-2.0-0D.lib and has 391,418 bytes, so it’d be pretty difficult to get them confused. But for vcpkg builds here, Debug and Release files are both called glib-2.0.lib and both have a size of 434,509 bytes.

And from what I’m seeing here, the same is true for the other vcpkg libraries. So if the goal is to attract new developers, someone’s pretty much bound to mix them up at some point. I guess Paul’s view / Robin’s view would be useful here.