I suspected that glibmm-2.4 might be a problem. Newer versions break the API.
I cannot think of an easy solution though. Yet since we may also run into this with Ardour on Linux at some point, we could vendor it and include libglimm-2.4 with Ardour’s source-code. Except… pangomm depends on glibmm, so we’d also have to include that.
Maybe it’s a good time to look into this right now, unless you can just build it using the recipe from vcpkg.io just using older source-code, or perhaps you have a flash of inspiration.
I must admit I’m confused now… @EZ4Stephen - when you started this thread you posted screenshots, having successfully built Ardour using MSYS and MinGW. So (presumably?) you were able to obtain compatible versions of glib and glibmm back then. Or did you maybe find pre-built libraries from somewhere?
With these changes, I’ve gone past a few more checks.
Currently at
Checking for ‘vamp-sdk’ >= 2.1 : not found
There’s glib2 and glibmm, so I did obtain compatible versions. Though it’s intriguing that I didn’t have the name problem on that occasion, but it came here.
Edit: I’m now at the following.
Checking for ‘rubberband’ : yes
Checking for ‘libusb-1.0’ >= 1.0.16 : not found
Checking for rubberband >= 3.0.0 : yes
Checking for sndfile RF64=>RIFF support : Found
Checking for int128 support : Not found, no int128 support.
Checking for ‘jack’ >= 1.9.10 : not found
Checking for clang : no
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’ : not found
Yes, I think Robin is saying that its API (some function names, for example) got changed so 2.68 will prevent other libraries from working, such as pangomm.
If I follow Robin’s link (to vcpkg.io) it suggests that mere users can add their own libraries (really?) Though if that’s possible, does it offer us a potential solution?
I’ve some contacts at Microsoft so I’ll try to find out if vcpkg still contains older versions of libraries.
It could be either. If function names (or function signatures) got changed, you’ll probably get errors when trying to link to other libraries. But if they’re more subtle changes (e.g. changes to the data in structs or classes) you’ll very likely get run time errors
I’ve run into a new problem: After running vcpkg install aubio, no aubio.pc file was made in my PKG_CONFIG_PATH (C:\dev\vcpkg\installed\x64-windows\lib\pkgconfig)
Extract from the config.log:
Checking for 'fftw3f'
['C:\\dev\\vcpkg\\installed\\x64-windows\\tools\\pkgconf\\pkg-config.bat', '--cflags', '--libs', 'fftw3f']
out: -IC:/dev/vcpkg/installed/x64-windows/include -LC:/dev/vcpkg/installed/x64-windows/lib -lfftw3f
yes
----------------------------------------------------
Checking for 'aubio' >= 0.3.2
['C:\\dev\\vcpkg\\installed\\x64-windows\\tools\\pkgconf\\pkg-config.bat', 'aubio >= 0.3.2', '--cflags', '--libs', 'aubio']
err: Package aubio was not found in the pkg-config search path.
Perhaps you should add the directory containing `aubio.pc'
to the PKG_CONFIG_PATH environment variable
Package 'aubio' not found
Package 'aubio' not found
not found
Wow, I got a reply back already! That’s VERY unusual Here’s what they said…
vcpkg generally tracks the latest versions of libraries. Older versions are not usually maintained once updated, unless you use a specific commit of the vcpkg repository that contained the earlier version (for example, glibmm 2.44). You can do this by checking out the corresponding Git commit where that version was still available.
I’m not sure if that means you can keep older versions of vcpkg somehow. Or if it means you can commit older libraries yourself if you need to keep them. Or if it means you can check out (say) glibmm2.80 and see if git will then let you revert it to glibmm2.44
In case it’s useful, I received another reply from Microsoft this morning. I’m not massively familiar with vcpkg but I don’t think switching to older libraries is quite as simple as I suggested above. Here’s what they said:-
vcpkg integrates with Git under the hood — each port in vcpkg is tied to a specific Git commit. If you want to use an older version of a library, you can check out an earlier commit of the vcpkg repository (for example, using git checkout ), and then run vcpkg install . That will build and install the version of the library corresponding to that commit.
This approach lets you reproduce older versions of packages, even if the current port has since been updated.
The obvious problem (I guess?) is that you’d need some way of knowing which of vcpkg’s earlier versions contained the release you’re looking for. So in practice, downloading earlier versions of a library might be a lot more difficult than it seems
You can always google the date a particular glibmm version (for instance) was released and then run git tag in the vcpkg git clone to see what tag is closest to that particular date and check out that tag (or one a reasonable amount of time after that).
Then have a look at the ports/glibmm/vcpkg.json (or ports/glibmm/portfile.cmake in older checkouts) file to see the exact version it corresponds to.
That said, glibmm appears to have been added to vcpkg in 2017, in commit 30f742160281, and that was version 2.52.1 :
Maybe it’s possible to just replace the URL with https://download.gnome.org/sources/glibmm/2.44/glibmm-2.44.0.tar.xz and the SHA512 with 1b0ac0425d24895507c0e0e8088a464c7ae2d289c47afa1c11f63278fc672ea8 and compile it but you may need to replace some of the dependency versions as well.
Replace the following in the root wscript:
if conf.options.cxx17 or platform == "darwin":
conf.check_cxx(cxxflags=["-std=c++17"])
cxx_flags.append('-std=c++17')
With:
if conf.options.cxx17 or platform == "darwin":
if compiler_name == 'msvc':
cxx_flags.append('/std:c++17')
else:
conf.check_cxx(cxxflags=["-std=c++17"])
cxx_flags.append('-std=c++17')
Also replace
'full-optimization' : '/O2',
with
'full-optimization' : ['/O2'],
Those were manual edits. I also dealt with the following error:
C:\dev\ardour\libs\pbd\pbd\signals.h(36): fatal error C1083: Cannot open include file: ‘glibmm/threads.h’: No such file or directory
Ah… regarding the errors Cannot open include file ‘ardourext/[whatever].h’ those files get generated by my .vcxproj file, when I’m building libpbd here. I could possibly upload a zip file containing those files but I remember that Ardour’s forum is quite limited as to what files are acceptable. Does anyone know if zip files are acceptable?
Probably a good idea… and as Peder explained, eariler versions can be found but I guess the downside is that earlier versions of all the libs needed for Ardour might be in multiple different versions of vcpkg, so it’ll quickly turn into a nightmare if we’re expecting newbies to find the support libs themselves.
For me, this has come full circle… if we want to attract new programmers for the non-linux builds, Paul and Robin need to think about providing pre-built support libraries (and corresponding header files). I guess the good bit is that those libraries only change very rarely nowadays - so it’s not like they’d need to be getting rebuilt all the time.
@EZ4Stephen - back around post#6 I mentioned that someone called Andre was the other guy who’d once built Ardour using MSVC. He just emailed me to say that for the support libs, he’d needed to create something called vcpkg overlays. I’m not quite sure what they are but it sounds like they’re some way of customizing vcpkg builds to add your own build requirements.
You’re probably already aware of overlays but in case you’re not, I’m just mentioning it, in case it’d be worth you reading up about them.
@EZ4Stephen I’ve pushed some code (mostly the sed stuff from your original guide) up to the Ardour repository that makes this all a bit more plug-and-play. I’ve also hooked up ccache and got ardev working for a smoother dev workflow. Tested and working on a fresh win11 VM. Here’s an updated guide:
MSYS
Install MSYS2
Open MSYS2 MINGW64
pacman -Syu
Open MSYS2 MINGW64 again
pacman -Syu again
Packages
pacman -S --noconfirm --needed git unzip make mingw-w64-x86_64-{toolchain,boost,glib2,glibmm,libsndfile,curl,libarchive,liblo,taglib,vamp-plugin-sdk,rubberband,aubio,cairomm,pangomm,jack2,serd,sord,sratom,lilv,libwebsockets,cmake,libusb}
Here’s what they said…