Sorry Stephen. After realising what the error was I’ve edited my post. Is your processor AMD or Intel? If it’s a processor issue there’s a good chance someone else will need to test this, rather than me.
It’s intel. Also: the python script uses classic mode, not manifest mode.
Edit: The option was wrong. Try manually clearing G:\vcpkg-stuff\gnu-windows\src\vcpkg\buildtrees.
Mine’s Intel too but if you’re building in classic mode doesn’t that mean you can’t use version overrides?
Yes, overriding is a manifest mode thing.
Aaaaaargh! I just got a reply to my bug report at vcpkg. My build issues are because I’ve been building on my G: drive which is the only drive here with enough space left - but it’s not NTFS format!!
1 Like
Okay… humbled by my rookie mistake I dug out an old USB memory stick (checking it was formatted as NTFS!!) and started again. At first I tried just building from your script (i.e. letting it download the latest vcpkg release) but that still fails, weirdly enough it bombs out while building libffi again!?! So I ditched that idea and switched to my slightly older download of vcpkg which pretty much got everything built. It took a dive when it came to @drobilla’s stuff (serd / sord / sratom etc) with this message:-
Downloading https://gitlab.com/drobilla/serd/-/archive/v0.32.8/serd-v0.32.8.tar.gz → drobilla-serd-v0.32.8.tar.gz
error: curl operation failed with error code 6 (Could not resolve hostname).
error: Not a transient network error, won’t retry download from https://gitlab.com/drobilla/serd/-/archive/v0.32.8/serd-v0.32.8.tar.gz
note: If you are using a proxy, please ensure your proxy settings are correct.
Possible causes are:
- You are actually using an HTTP proxy, but setting HTTPS_PROXY variable to
https://address:port.
This is not correct, becausehttps://prefix claims the proxy is an HTTPS proxy, while your proxy (v2ray, shadowsocksr, etc…) is an HTTP proxy.
Try settinghttp://address:portto both HTTP_PROXY and HTTPS_PROXY instead.- If you are using Windows, vcpkg will automatically use your Windows IE Proxy Settings set by your proxy software. See: https://github.com/microsoft/vcpkg-tool/pull/77
The value set by your proxy might be wrong, or have samehttps://prefix issue.- Your proxy’s remote server is out of service.
If you believe this is not a temporary download server failure and vcpkg needs to be changed to download this file from a different location, please submit an issue to Issues · microsoft/vcpkg · GitHub
It built the previous 140 libraries okay so I wonder if drobilla’s host has changed (or offline maybe??)
Anyway… the 64K dollar question is “what’s the point of all this??” We discovered eons ago that building everything in classic mode results in a bunch of libs which aren’t ABI compatible with Ardour 
Tried re-running the script after the error, see if it errors out again?
Only libsigcpp/glibmm/cairomm/pangomm had the ABI issues, other packages were just fine though having slightly different library names or other subtleties that had to be taken into account.
The python script makes use of ports to install compatible versions of those packages which would otherwise be incompatible.
Yes, it didn’t help
For my money I still think that glib/cairo/pango should get added to Ardour’s libs/tk branch and built within ardour (along with their mm cousins).
Would Paul and Robin be willing to introduce a libs/tk-test branch which could get optionally built or ignored? You could then work on getting those troublesome ones to work while Robin and Paul could ignore them until they were proven.
The reason we put gtk2 (or a fork thereof) into our tree was the impending end-of-life for GTK2 on Linux. No such condition exists for glib or cairo or pango.
I think Stephen and I appreciate that but it’d solve a lot of Stephen’s problems (and if it was optional you & Robin could just ignore it…)
My current main problem is to make it easier for others to download the dependencies, and while there’s some logic that vendoring in packages makes installing packages easier by needing fewer external packages, it’s not suitable here, as Paul explained.
I intend on sharing the python script into the forums as a codeblock once its proven to work for anyone other than me. Until then, I suppose things will slow down here for anywhere from a day to a month.
Trying to lighten the mood, @John_E you could try passing --keep-going to the latest vcpkg. As in, editing line 297 of the script to
run([str(_vcpkg_exe), f"--overlay-ports={_overlay_dir}", "install", *packages , "--keep-going"], cwd=_vcpkg_dir)
From the vcpkg website:
Continue the install plan after the first failure.
By default, vcpkg will stop at the first package build failure. This flag instructs vcpkg to continue building and installing other parts of the install plan that don’t depend upon the failed package.
The purpose is to see what package the build fails in after the failure in gperf. If a 2nd package after gperf fails, we can choose to pivot to xmake/xrepo. If not, we know that everything hinges on changing the build system for gperf and no other package.
I added that here but as it turned out, it wasn’t needed (drobilla’s host must have been temporarily offline). Anyway, everything builds fine here now. I can’t get further than libffi if I build from the latest vcpkg but I’ve had quite a few issues with libffi for some reason. Give it a try at your end and if it works for you, let’s just assume there’s something weird going on at my end.
I’m close to done with the xmake path. All mandatory dependencies: Available. Installing them in places that isn’t the cache: Done. And to my surprise: .pc files were generated if not installed from the packages itself, automatically. Saved me trouble I was expecting.
Current problem: Figuring out how to get all transitive dependencies’ files to also get installed, not just the ones listed in the file.
It might be practical for me to just list out all dependencies needing .pc files than relying on the transitive property. I’ll figure something out.
Passed configure step, but the boost includes are a little mixed up. Trying to figure out how to reinstall boost such that includes don’t give errors.
Out of interest, does xmake compile boost or just give you the headers? I was always confused about why vcpkg builds boost as DLL’s. Boost is pretty much all template based so it’s useable just from the header files.
If you don’t add additional config to it, it is compiled (or precompiled). Some of the boost libraries are header-only, others aren’t.
That being said, the boost package on xrepo is a bit of a maze to me. Maybe I can help make it better, but I can only help with the errors I face. I don’t want to deal with installing ALL boost packages. And I presume that the default for boost on xmake isn’t to build all packages.
True… for a long time boost-regex needed to be compiled but that’s been converted to headers-only now.
In one or two days I’ll make a new post “As of July 2026” that links the vcpkg script but focuses more on xmake and its detailing getting the dependencies, how much is possible and such.
One fun detail: Seems like installing all libraries takes <25 minutes. (Maybe that’s only the case for release?)
Currently my script (not shared) passes configure, but excludes libusb and jack because of their .pc file names, and then fails at linking pbd, and/or some boost header include errors at temporal.
Things to do (that I know of), that I will have to fix upstream in xmake-repo:
- Fix jack2.pc to become jack.pc
- Fix libusb.pc to become libusb-1.0.pc
- Fix libintl.h to not have __declspec(dllimport) in line 52
- Fix …boost\multiprecision\detail\number_base.hpp(34,10): fatal error C1083: Cannot open include file: ‘boost/math/tools/complex.hpp’: No such file or directory
Also there’s
- Fix error LNK2001: unresolved external symbol __imp_libintl_dgettext; …ardour\build\libs\pbd\pbd.dll : fatal error LNK1120: 1 unresolved externals
The last error, I’m unsure if it’s an xrepo and/or ardour [wscript(s)] issue. My vcpkg runs didn’t give any such error. MinGW has a line mentioning intl, but just in the root wscript. No match was found for “intl” in pbd’s wscript, where I got the missing symbol errors. I’m leaning on this being an xrepo issue, but I’m uncertain.
Maybe speak to the guys at xrepo. My guess would be that some of their packages are getting built against gettext-libintl whereas others are using proxy-libintl. ‘gettext-libintl\libintl.h’ definitely declares libintl_dgettext() but on my system at least, ‘proxy-libintl\libintl.h’ doesn’t declare it.
vcpkg seems to use gettext-libintl exclusively.