Windows native compilation 2

It applies to Linux too, and is the reason why we do not provide support for distro-built versions but instead provide our own all-inclusive ready-to-run Linux binary.

The patches we use when creating our own build-stack for the releases are all available. Few of them are absolutely critical, all of them are of some importance.

Ironically, probably the most significant one is actually for macOS - a patch to GTK+ that changes how mouse scroll handling is done. Upstream would not accept it because it alters the semantics of scroll events and the data structures used.

Any news on this? Does Ardour start using the “Dummy” backend?

As for the other errors:

  • ardourcp.dll is a library used by control protocols, it’s expected to not have a protocol-descriptor.
  • other ctrl surface seems to load. The only ones that fail are ardour_contourdesign.dll and ardour_push2.dll those two use libusb. maybe a missing symbol, or linker issue regarding libusb?
  • You could try to configure Ardour with --libjack=weak that may help with jack_audiobackend.dll in case the issue is due to missing libjack symbols.

I moved one step forward (I configured including --keepflags --libjack=weak). It still gives the missing descriptor error in ardourcp.dll, but it seems to load the audio backends now, and proceed.

As I am hand-picking each dll, to see which one is really required, and I see the errors of missing libraries when I launch ardour, I was at a point where the exe was giving no error, but maybe some other required dll was still missing. After I added the libusb dll, it seems that the backends could be loaded.

The error I get now, supposedly, is also due to something missing. I saw that clearlooks underwent changes… maybe you can point me out.

F:\a\usr\src\ardour6\bin>Ardour6.0.pre0.3103 (built using 6.0-pre0-3103-gb942eecc9c and GCC version 9.2.0)
Ardour: [INFO]: QPC timer microseconds per tick: 0.1

Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
Ardour: [INFO]: Loading system configuration file F:\a\usr\src\ardour6\share\ardour6\system_config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 3950X 16-Core Processor
Ardour: [INFO]: No H/W specific optimizations in use
Ardour: [ERROR]: ControlProtocolManager: module “F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardourcp.dll” has no descriptor function.
Ardour: [ERROR]: ‘protocol_descriptor’: The specified procedure could not be found.
Ardour: [INFO]: Loading default ui configuration file F:\a\usr\src\ardour6\share\ardour6\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\phantom\AppData\Local\Ardour6\ui_config
Ardour: [INFO]: Loading color file F:\a\usr\src\ardour6\share\ardour6\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file F:\a\usr\src\ardour6\share\ardour6\clearlooks.rc

(ardour-6.0.pre0.3103.exe:2528): Gtk-WARNING **: 05:46:00.137: Unable to locate theme engine in module_path: “clearlooks”,

(ardour-6.0.pre0.3103.exe:2528): Gtk-WARNING **: 05:46:00.153: Unable to locate theme engine in module_path: “clearlooks”,
Ardour: [INFO]: Loading bindings from F:\a\usr\src\ardour6\share\ardour6\ardour.keys
Loading ui configuration file F:\a\usr\src\ardour6\share\ardour6\clearlooks.rc

(ardour-6.0.pre0.3103.exe:2528): Gtk-WARNING **: 05:46:00.168: Unable to locate theme engine in module_path: “clearlooks”,

(ardour-6.0.pre0.3103.exe:2528): Gtk-WARNING **: 05:46:00.168: Unable to locate theme engine in module_path: “clearlooks”,
terminate called after throwing an instance of ‘failed_constructor’
what(): failed constructor

Ardour now ends with that error, no other message whatsover.

I guess I figured out a new bit.

I installed mingw-w64-x86_64-gtk-engines.
Then, I copied the pertinent dlls in my $ARDOUR_PKG/lib/gtk-2.0/engines/

Now, Gtk does not complain about not being able to locate the theme engine. I only get the failed constructor error. Probably still something missing… and no clue what it might be.

F:\a\usr\src\ardour6\bin>Ardour6.0.pre0.3103 (built using 6.0-pre0-3103-gb942eecc9c and GCC version 9.2.0)
Ardour: [INFO]: QPC timer microseconds per tick: 0.1

Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
Ardour: [INFO]: Loading system configuration file F:\a\usr\src\ardour6\share\ardour6\system_config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 3950X 16-Core Processor
Ardour: [INFO]: No H/W specific optimizations in use
Ardour: [ERROR]: ControlProtocolManager: module “F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardourcp.dll” has no descriptor function.
Ardour: [ERROR]: ‘protocol_descriptor’: The specified procedure could not be found.
Ardour: [INFO]: Loading default ui configuration file F:\a\usr\src\ardour6\share\ardour6\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\phantom\AppData\Local\Ardour6\ui_config
Ardour: [INFO]: Loading color file F:\a\usr\src\ardour6\share\ardour6\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file F:\a\usr\src\ardour6\share\ardour6\clearlooks.rc
Ardour: [INFO]: Loading bindings from F:\a\usr\src\ardour6\share\ardour6\ardour.keys
Loading ui configuration file F:\a\usr\src\ardour6\share\ardour6\clearlooks.rc
terminate called after throwing an instance of ‘failed_constructor’
what(): failed constructor

If I launch ardour through the mingw shell, I get some more informative messages (cannot construct splash screen image):

$ ./ardour-6.0.pre0.3103.exe
ARDOUR_DATA_PATH not set in environment
Cannot find ArdourSans TrueType font
Cannot register ArdourSans TrueType font with windows gdi.
bind txt domain [gtk2_ardour6] to F:\a\usr\src\ardour6\share\ardour6\locale
Ardour6.0.pre0.3103 (built using 6.0-pre0-3103-gb942eecc9c and GCC version 9.2.0)
Ardour: [INFO]: QPC timer microseconds per tick: 0.1

Ardour: [INFO]: MMCSS Initialized
Ardour: [INFO]: Your system is configured to limit Ardour to 2048 open files
ARDOUR_CONFIG_PATH not set in environment
Ardour: [INFO]: Loading system configuration file F:\a\usr\src\ardour6\share\ardour6\system_config
Ardour: [INFO]: CPU vendor: AuthenticAMD
Ardour: [INFO]: AVX-capable processor
Ardour: [INFO]: CPU brand: AMD Ryzen 9 3950X 16-Core Processor
Ardour: [INFO]: No H/W specific optimizations in use
Ardour: [ERROR]: ControlProtocolManager: module “F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardourcp.dll” has no descriptor function.
Ardour: [ERROR]: ‘protocol_descriptor’: The specified procedure could not be found.
setting default config
default current master (back) is MIDI Clock
Ardour: [INFO]: Loading default ui configuration file F:\a\usr\src\ardour6\share\ardour6\default_ui_config
Ardour: [INFO]: Loading user ui configuration file C:\Users\phantom\AppData\Local\Ardour6\ui_config
Color shuttle bg not found
Color play head not found
Ardour: [INFO]: Loading color file F:\a\usr\src\ardour6\share\ardour6\themes\dark-ardour.colors
Ardour: [INFO]: Loading ui configuration file F:\a\usr\src\ardour6\share\ardour6\clearlooks.rc
Ardour: [INFO]: Loading bindings from F:\a\usr\src\ardour6\share\ardour6\ardour.keys
Loading ui configuration file F:\a\usr\src\ardour6\share\ardour6\clearlooks.rc
Cannot construct splash screen image
terminate called after throwing an instance of ‘failed_constructor’
what(): failed constructor

It seems an issue with gtk and clearlooks.

I’m not 100% sure of the Windows situation, but on Linux and macOS, it isn’t possible to run the executable as-is.

On Linux, it gets wrapped by a shell script that sets a bunch of variables in the environment.
On macOS, it gets converted into an app (aka “bundle”) and when it discovers this to be the case, it sets up a bunch of variables in the environment.

There is a script in the source tree called “ardev” that we use to do in-tree runs (thus avoiding the need to package the result into a “runnable” form.

Note that this is similar to how Firefox works too (invoked by a shell)

With
ldd ardour-*.exe | grep “not found”
I saw that I have no missing dependencies now. So, it seems all set correctly. At this point, it must be just a packaging issue.
Checking splash.cc, I see that ardour_data_search_path() is called, which is in filesystem_path.cc. There, it searches for the ARDOUR_DATA_PATH environment variable. Probably I am missing that.

I have packaged everything with the correct paths (at least I guess). I was investigating Paul’s suggestions, checking the ardev files. There is one for windows too. From what I see, they are meant to allow the ardour executable run inside the development folder.
Instead, I am packaging everything, with my packaging script. It puts every file in a directory tree that is same like for the ardour 5 windows distro. I only change the folder called ardour5 into ardour6. Thus, I would expect share/ardour6/resources to be found (it contains the splash images). Apparently, it’s not so.
Do you know how I can find where ardour searches its internal paths? Or how they should be?

By the way, even if I export ARDOUR_DATA_PATH explicitly, it doesn’t work:

export ARDOUR_DATA_PATH=/usr/src/ardour6/share/ardour6/

It gives the same error. Thus, I suspect there is something more to the path.

Sorry to post so many times. I got it running with the ardev-win script. I attach a screenshot.

Now, I still need to understand what is wrong in the path when I pack it. Any clue appreciated.

aquilarubra wrote:
" Now, I still need to understand what is wrong in the path when I pack it. Any clue appreciated."

Sorry to come late to the discussion (I only signed up today!!)

Your ‘gtk2_ardour’ folder contains some .cc source files which all start with ‘bundle_env’. You only need 1 of them but there are different versions for Linux, Mac and Windows (also… on Windows there are different versions for mingw or MSVC). I’d guess that you’re probably compiling the wrong version.

Or… if you’re correctly using the mingw version, maybe it’s out of date now (AFAIK there’s no-one else who currently builds with mingw so it probably hasn’t been updated for a while). As an aside…

Ardour: [ERROR]: ControlProtocolManager: module “F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardourcp.dll” has no descriptor function.
Ardour: [ERROR]: ‘protocol_descriptor’: The specified procedure could not be found.

A mingw build might be different for some reason - but in my build, that file is called “ardour_cp.dll” (containing an underscore). And it isn’t in my ‘surfaces’ folder either. The other devs will correct me if I’m wrong about this but on your system, I’ve a feeling it should be in ‘F:\a\usr\src\ardour6\bin’

Hi John, interesting points.
I found that bundle_env_mingw.cc is called properly.

I double checked, but in my system I get ardourcp.dll and not ardour_cp.dll. Anyway, despite the error, now the backends are loaded successfully and it doesn’t matter.

My mingw installation is update to the latest packages (mingw is 9.2.0). The few custom libraries that are not in the msys2 repository I compiled myself, and they are all in their last available version.

With my latest setup, I can now compile ardour 5.12 and 6 in release and debug mode successfully. The issue is at run time.

If I run ./ardev-win, it will load and I can work (however, there are the same seg faults that I experienced with ardour 6 when I reload a project due to wrong memory access; I will go back to this when I fix the build process).

When I pack everything in a different folder, then I have the issue when loading images. Ardour v6 won’t load the splash screen (a png file) and crash.
Ardour 5.12 also crashes because of a png file. It is a bit more explicit:

Caught PixbufError: Couldn▒t recognize the image file format for file ▒F:\a\usr\src\ardour5\share\ardour5\icons\zoom_in_cursor.png▒
Exception code=0xc0000005 flags=0x0 at 0x000000006A14283B. Access violation - attempting to read data at address 0x0000000000000000
Segmentation fault

I checked pixbuf, but it is compiled against libpng… so it looks a bit weird. I suspect it is the same problem in both cases.

Some of your issues sound like a possible mismatch between DLL’s and header files. Am I right in thinking you’ve used pre-built support libraries? (cairo / pango / gtk+ etc)

If you haven’t built those modules yourself you need to be certain that you’re using the correct header files which correspond to whichever version of the DLL you’ve chosen. You mustn’t use arbitrary headers from some earlier (or later) version.

You are right, I used pre-built packages. As they are in pacman format, headers are bundled with the compiled objects. Thus, there is no way there is a mismatch.
My msys2 installation is also completely fresh. Therefore, it is impossible that there are previous installations.

2 posts were split to a new topic: Changing Email address

Hi aquilarubra - I just checked ‘bundle_env_msvc.cc’ and it’s setting all the following environment variables:-

ARDOUR_DLL_PATH
ARDOUR_DATA_PATH
ARDOUR_CONFIG_PATH
ARDOUR_INSTANT_XML_PATH
LADSPA_PATH
SUIL_MODULE_DIR
VAMP_PATH
ARDOUR_CONTROL_SURFACE_PATH
GTK_LOCALEDIR
GTK_PATH
$HOME

However… ‘bundle_env_mingw.cc’ only sets these ones:-

GTK_LOCALEDIR
VAMP_PATH
SUIL_MODULE_DIR
ARDOUR_SELF

So my guess would be that ‘ardev-win’ must add the missing ones to your system PATH (and that’s why it runs okay if you use ardev-win).

When not running from the source-tree, no environment variable need to be set for the windows binary.

All paths are set relative to the main binary, see windows_package_directory_path()

That’s what I figured out. If you have the correct tree structure, ardour finds everything. But what is this tree structure?

pretty much unix-like: lib for architecture dependent file, share for arch independent files, LV2, LADSPA etc per FHS in subdirs.

waf install puts everything in the right place. That’s how windows packages are built: just install it to a DESTDIR, then create an installer from that.

In the true it installs in a unix way. But now I can see a directory tree at least. I will rework my pack script and report back. In mingw environment, the install was launching fine at least.

This topic was automatically closed after 182 days. New replies are no longer allowed.