Windows native compilation 2

Installation & Configuration Windows
#12

"So, I had a working setup last year. I could compile and run Ardour 6. "

Paul has told him back in October 2018, and 3 days ago that the latest Ardour 6** is still in “pre-alpha” and is not something we can be providing user-feedback.

It’s still off-topic even in regards to what he’s been told multiple times. I’ve been told the same thing by Paul and Robin on the “pre-alpha” state.

So yes, it’s really out-of-line by multiple factors.

Also if one reads careful on the prior thread, a walkthrough was encouraged, not a plea-for-help. A walkthrough is something that works from start to finish.

#13

Sorry, that is my fault. It’s locked for everyone except admins. I had a reply drafted, but didn’t initially post it because I’m unsure if it would be helpful. When I later clicked “reply”, it was not affected by the lock.

Anyway, I still stand by the argument that it’s very likely an issue with your setup, due to the following reasoning:

  • nothing has changed regarding symbol visibility in Ardour for at least 10 years
  • you had a working setup in the past
  • it works for others (mingw x-compile as well as MSVC builds)

I don’t have an explanation.
Maybe some compiler defaults have changed, or maybe the error message is misleading.

The only obvious issue in the instructions that you’ve posted is that the current configure like does not include --keepflags (so custom CFLAGS, CXXFLAGS are not taken into account).

I don’t have a Windows system to reproduce, so unless someone else jumps it, it would be helpful to also include the output of the waf configure stage.

Since you are the only one with this issue, you are most likely also alone with debugging this.
As was mentioned already, we don’t generally have the resources to provide support for building from source.

If this is really a visibility issue, check what ARDOURSURFACE_API is defined to.

It seems the dummy backend is found (at least you configure --with-backends=jack,portaudio,dummy and there is no error about that module). I hazard a guess that the others .dll have missing symbols, and this is a different issue. Maybe check with http://www.dependencywalker.com/

#14

@x42 the problem with this OP topic is the author describes trying Ardour 6 pre-alpha a year ago and describes that it is not stable. They’re kind of reciting the incorrect usability on the ready-state. fwiw, I think the dependency-walker has been replaced by things better than it with “systernals” tools – I stopped using Windows like a decade ago, and iirc that tool was a favorite of mine and there was something better than it though I don’t remember exactly what tool that would be – perhaps something with systernals…

#15

Thanks x42, indeed any idea is welcome. I will try again with --keepflags and report. I removed it only in the last couple of days because I didn’t see any difference with it and I could see that after ./waf configure my custom CFLAGS and CXXFLAGS were there. I can also tell that waf uses them, because without them set, compilation will fail.

I will post here also the entire ./waf configure, just give me a couple of days. It’s very specular to the log in nightly if not same.

I suspect there were changes in gcc, which are causing the issue. Version 9.2.0 seems quite strict. The thing is that Ardor, because of retro-compatibility, tends to use older libraries and an older compiler. Arch and msys2 are bleeding edge, so they introduce all the complexities of the new. Therefore, I don’t think it’s a issue with my setup, but it is probably a issue that I use just the latest libraries available. It also means that the same issues I am facing today, you are likely to face in a couple of years.

I also had the idea to pass --export-all-symbols to the linker and see whether the descriptor gets included.

I am probably the only one debugging this, but I am willing to do it, hoping it will be helpful. As I can compile Ardour successfully, probably very little is needed to get it running correctly, as it already works with cross-compiling and MSVC.

#16

I forgot I had the logs around. Here they are for my latest successful build.

export CFLAGS="-mstackrealign -mxsave -mmmx -msse"
export CPPFLAGS="-mstackrealign -mxsave -mmmx -msse"

$ ./waf configure --dist-target=mingw --windows-vst --ptformat --with-backends=jack,portaudio,dummy --optimize
Setting top to : /usr/src/ardour
Setting out to : /usr/src/ardour/build
Checking for ‘gcc’ (c compiler) : /mingw64/bin/gcc
Checking for ‘g++’ (c++ compiler) : /mingw64/bin/g++
Checking for program windres : /mingw64/bin/windres
Global Configuration

  • Install prefix : /usr/local
  • 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.56 : ok
    Checking for program pkg-config : /mingw64/bin/pkg-config
    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.6 : yes
    Checking for ‘vamp-sdk’ >= 2.1 : yes
    Checking for ‘vamp-hostsdk’ >= 2.1 : yes
    Checking for ‘rubberband’ : yes
    Checking for sndfile RF64=>RIFF support : Found
    Checking for function htonl : yes
    Checking for function regcomp : yes
    Checking for pthread posix semaphore : Found
    Checking for clang : no
    Checking for library setupapi : yes
    Checking for ‘fftw3f’ : yes
    Checking for ‘aubio’ >= 0.3.2 : yes
    Checking for ‘aubio’ >= 0.4.0 : yes
    Checking for ‘libxml-2.0’ : yes
    Checking for ‘sigc+±2.0’ >= 2.0 : yes
    Checking for function getmntent : not found
    Checking for header execinfo.h : not found
    Checking for header unistd.h : yes
    Checking for function posix_memalign : no
    Checking for function localtime_r : not found
    Checking for header boost/shared_ptr.hpp : yes
    Checking for header boost/weak_ptr.hpp : yes
    Checking for library ole32 : yes
    Checking for ‘cppunit’ >= 1.12.0 : yes
    Checking for header boost/shared_ptr.hpp : yes
    Checking for header boost/weak_ptr.hpp : yes
    Checking for header boost/shared_ptr.hpp : yes
    Checking for header boost/weak_ptr.hpp : yes
    Checking for ‘libusb-1.0’ : yes
    Checking for header cwiid.h : not found
    Checking for ‘pangomm-1.4’ >= 1.4 : yes
    Checking for ‘cairomm-1.0’ >= 1.8.4 : yes
    Checking for ‘jack’ >= 0.121.0 : yes
    Checking for ‘portaudio-2.0’ >= 19 : yes
    Checking for JACK metadata API : ok
    Checking for header pa_asio.h : yes
    Checking for program gas,as,gcc : /mingw64/bin/as
    Checking for ‘samplerate’ >= 0.1.0 : yes
    Checking for ‘lv2’ >= 1.2.0 : yes
    Checking for ‘lv2’ >= 1.10.0 : 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 ‘suil-0’ >= 0.6.0 : 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 : yes
    Checking for header boost/shared_ptr.hpp : yes
    Checking for header boost/weak_ptr.hpp : yes
    Checking for header boost/scoped_ptr.hpp : yes
    Checking for header boost/ptr_container/ptr_list.hpp : yes
    Checking for library gdi32 : yes
    Checking for ‘gtkmm-2.4’ >= 2.8 : yes
    Checking for ‘gtk±2.0’ >= 2.12.1 : yes
    Checking for ‘samplerate’ >= 0.1.7 : yes
    Checking for header boost/shared_ptr.hpp : yes
    Checking for header boost/format.hpp : 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 ‘gtk±2.0’ >= 2.18 : yes
    Checking for ‘x11’ >= 1.1 : not found
    Checking for ‘pangoft2’ >= 1.36.8 : yes
    Checking for ‘fontconfig’ : yes
    Checking for header boost/shared_ptr.hpp : yes
    Checking for header boost/weak_ptr.hpp : yes
  • build session-utils : yes
    Checking for library gdi32 : yes
    Checking for function readline : yes
  • Build documentation : False
  • Debuggable build : False
  • Export all symbols (backtrace) : False
  • Install prefix : /usr/local
  • 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
  • Aubio : True
  • AudioUnits : False
  • Build target : mingw
  • Canvas Test UI : False
  • Beatbox test app : False
  • CoreAudio : False
  • CoreAudio 10.5 compat : False
  • Debug RT allocations : False
  • Debug Symbols : False
  • Denormal exceptions : False
  • FLAC : True
  • FPU optimization : True
  • Freedesktop files : False
  • Libjack linking : weak
  • Libjack metadata : True
  • Lua Binding Doc : False
  • Lua Commandline Tool : True
  • 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
  • Process thread timing : False
  • Program name : Ardour
  • Samplerate : True
  • PT format : True
  • PTW32 Semaphore : False
  • Threaded WaveViews : True
  • Translation : True
  • Unit tests : False
  • Use LLD linker : False
  • 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
  • C compiler flags : [’-I/usr/src/ardour’, ‘-mstackrealign’, ‘-mxsave’, ‘-mmmx’, ‘-msse’, ‘-mstackrealign’, ‘-mxsave’, ‘-mmmx’, ‘-msse’, ‘-DHAVE_RF64_RIFF’, ‘-DPLATFORM_WINDOWS’, ‘-DCOMPILER_MINGW’, ‘-DUSE_CAIRO_IMAGE_SURFACE’, ‘-DWAF_BUILD’, ‘-DNDEBUG’, ‘-fshow-column’, ‘-O3’, ‘-fomit-frame-pointer’, ‘-ffast-math’, ‘-fstrength-reduce’, ‘-pipe’, ‘-DARCH_X86’, ‘-msse’, ‘-mfpmath=sse’, ‘-DUSE_XMMINTRIN’, ‘-masm=att’, ‘-Wall’, ‘-Wpointer-arith’, ‘-Wcast-qual’, ‘-Wcast-align’, ‘-Wno-unused-parameter’, ‘-DBOOST_SYSTEM_NO_DEPRECATED’, ‘-D_ISOC9X_SOURCE’, ‘-D_LARGEFILE64_SOURCE’, ‘-D_FILE_OFFSET_BITS=64’, ‘-DPROGRAM_NAME=“Ardour”’, ‘-DPROGRAM_VERSION=“6”’, ‘-Wstrict-prototypes’, ‘-Wmissing-prototypes’]
  • C++ compiler flags : [’-I/usr/src/ardour’, ‘-mstackrealign’, ‘-mxsave’, ‘-mmmx’, ‘-msse’, ‘-DHAVE_RF64_RIFF’, ‘-DPLATFORM_WINDOWS’, ‘-DCOMPILER_MINGW’, ‘-DUSE_CAIRO_IMAGE_SURFACE’, ‘-DWAF_BUILD’, ‘-DNDEBUG’, ‘-fshow-column’, ‘-O3’, ‘-fomit-frame-pointer’, ‘-ffast-math’, ‘-fstrength-reduce’, ‘-pipe’, ‘-DARCH_X86’, ‘-msse’, ‘-mfpmath=sse’, ‘-DUSE_XMMINTRIN’, ‘-masm=att’, ‘-Wall’, ‘-Wpointer-arith’, ‘-Wcast-qual’, ‘-Wcast-align’, ‘-Wno-unused-parameter’, ‘-DBOOST_SYSTEM_NO_DEPRECATED’, ‘-D_ISOC9X_SOURCE’, ‘-D_LARGEFILE64_SOURCE’, ‘-D_FILE_OFFSET_BITS=64’, ‘-DPROGRAM_NAME=“Ardour”’, ‘-DPROGRAM_VERSION=“6”’, ‘-Woverloaded-virtual’, ‘-Wno-unused-local-typedefs’, ‘-D__STDC_LIMIT_MACROS’, ‘-D__STDC_FORMAT_MACROS’, ‘-DCANVAS_COMPATIBILITY’, ‘-DCANVAS_DEBUG’]
  • Linker flags : [’-Wl,–enable-auto-import’, ‘-Wl,–enable-auto-import’]
#17

Ardour is known to compile and run on Arch (Linux) with gcc-9.2 (except some issues with waf python2/3), however with a sub-standard GUI, and user-experience as well as some subtle bugs if you use Arch-Linux provided libs as-is without customizing them. You’re also on your own there. We hand-pick libs for a reason.

However I don’t know about msys2.

Edit: This ties in with your earlier criticism…

Ardour devs contribute to many of those libraries and it’d be a shame if they’d be Ardour only. Ardour benefits significantly from GPL tools and libraries and would not exist were it not for the many projects to build upon.

#18

That’s right. Plus, mingw is a subset of gcc. So, I don’t expect it works same like in Arch Linux. Probably a cross-compile from Arch would work better. But anyway… that’s what msys2 is, and I can definitely compile Ardour.

#19

Ok time to clarify a few things, x42 already mentioned his post came in after the lock because he is an admin and had already drafted it.

I locked the previous thread for all users. The only people able to post in it were moderators and admins. I did this because it degraded to personal attacks quickly. Had I been around I might have done the same to this thread earlier, but as I am just now seeing this and it has recovered into somewhat useful technical discussion again, I may let it go for a bit and see how it goes. Obviously I shouldn’t even need to say this but I (Or any moderator) can close this thread as well if we feel it is not in the spirit of these forums. This serves as yet another fair warning for any conversations happening.

Ardour 6 at this time had no business being discussed on these forums and discussion about issues with it will likely result in a thread being closed, hidden, deleted, etc. as determined appropriate by the moderator at the time. This was clarified repeatedly in the past and is a long standing tradition in this community that we do not discuss major revisions before they are in a state to be publicly tested (Typically at least Beta testing). This prevents flat out wrong information from being disseminated in what is essentially an eternal record that is the internet that others might then when searching for issues that actually exist but may not have anything to do with issues that come up during testing.

Likewise there should be no expectation of support for any paths/choices/etc. taken trying to use Ardour in a way that is not expected. For instance compiling it on Windows native is going to involve some work and should only be attempted by those willing to put in that work and with the knowledge to do it themselves with the full understanding they are on their own.

This support also applies when discussing building with non-standard libs, etc. And realistically official support shouldn’t be expected outside of the official packages. Community support is always welcome of course, and if multiple people wish to discuss the technicalities they are welcome to, but at some point we may ask it not to happen here and instead happen over IRC or in a different forum to help keep this forum focused more on the software as designed and written and existing.

#20

Ok, all clear. My intent was just to see if there was anybody interested in my path. And if something useful comes out, it may enrich the Ardour code too and open up new possibilities.

#21

I am curious what the goal/purpose for compiling Ardour natively in Windows is. I have used the pre-compiled binaries from this site on Windows for years without any issues. Is there a performance advantage you are trying to obtain or is this purely an academic exercise?

1 Like
#22

Surely academic exercise.

I have another question. Ardour compilation is recommended against specific versions of libraries, plus one-two libraries have been a little customized. It is said that Ardour can be compiled without those customizations, but it won’t look as beautiful.

Now, I thought that this does not apply to Linux, but only to Windows, because there are so many Linux distros and it is unlikely that they have the exact version of libs that Ardour recommends.

This brings me to question why would it be so important on Windows. At the end, it either compiles or not. I tend to think that it should compile everywhere.

#23

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.

#24

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

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.

#26

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

#27

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.

#28

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)

#29

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?

#30

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.

#31

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.

ardour
ardour2503×1531 297 KB