Windows native compilation 2

Installation & Configuration Windows
#1

As the previous thread is locked for me only (good behaviour, Ardour tribe, insult and then prevent posting on relevant technical details), I am opening another thread, hopefully just technical.

Answering to x42 polite reply, I am aware that others compiled Ardour in mingw, but that was a few years ago and not even advised, as it used many custom libraries.
Just to make it clear, it costed me a lot of effort and time to get to the result I am now. I had a computer that needed 10 hours to compile Ardour, and I did that a hundred times to figure out every detail. If I post about a bug, it means that it is relevant, because all the other issues I solved already.

So, I had a working setup last year. I could compile and run Ardour 6. However, there were many issues. I could create a project, use Ardour, but when I was reopening the project, it was crashing. I wanted to check the situation this year, as gcc 9 was just released last year and there were too many variables that had to be accounted for.

This year, I decided to re-create the entire project from scratch and document it. The goal was to use just the default msys2 libraries. So, when you say that it is an issue with my libraries/environment, it’s not. The only library I compile myself that is already in the msys2 repository is portaudio, to include asio support. And that’s why libraries such as bcrypt are necessary with the default msys2 packages. But that’s no problem, I figured all that out.

I published the complete instructions here, for easy replication: https://musicsecrets.euniversity.pub/ardour.html

I guess you are using gcc v8 for cross-compiling, because in v9 many things changed. I could now reduce the library requirements (CFLAGS and CPPFLAGS) to the minimum and I know how to compile with gcc v9.2.0. Some flags such as -DBUILD_SSE_OPTIMIZATIONS that you are using cause undefined symbols with msys2 latest default setup. Strangely, I still have to solve undefined symbols for the debug version compilation, which seems to require a different approach, but I am not that interested in fixing that too.

With my current instructions, you can compile everything for the release version. I build PKGBUILD files for the few libraries that are not included in msys2 repositories. Everything is very default, for easy replication.

Now, the generated ardourcp.dll definitely lacks the descriptor function. I could verify it with
nm -g --defined-only ardourcp.dll
and it’s not there.

The ladspa solution had this test:
#ifdef _WIN32
__declspec(dllexport)
#else
attribute ((visibility (“default”)))
#endif
const LADSPA_Descriptor * ladspa_descriptor(unsigned long index)

Therefore, the instruction for _WIN32 is not the same for Linux, which involves visibility. I guess this is the issue, but I am getting a bit lost in Ardour code.

I guess contributions are also bug reporting, not necessarily coming with a ready fix to the code, and it took my time to figure everything out till this point. If the Ardour team is not interested, no problem and no issue if you don’t respond. Maybe somebody else will be interested and respond.

I paste below the error:

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: [ERROR]: ControlProtocolManager: cannot load module “F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardour_contourdesign.dll” (‘F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardour_contourdesign.dll’: The specified module could not be found.)
Ardour: [ERROR]: ControlProtocolManager: cannot load module “F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardour_push2.dll” (‘F:\a\usr\src\ardour6\lib\ardour6\surfaces\ardour_push2.dll’: The specified module could not be found.)
Ardour: [ERROR]: AudioEngine: cannot load module “F:\a\usr\src\ardour6\lib\ardour6\backends\jack_audiobackend.dll” (‘F:\a\usr\src\ardour6\lib\ardour6\backends\jack_audiobackend.dll’: The specified module could not be found.)
Ardour: [ERROR]: AudioEngine: cannot load module “F:\a\usr\src\ardour6\lib\ardour6\backends\portaudio_callback_backend.dll” (‘F:\a\usr\src\ardour6\lib\ardour6\backends\portaudio_callback_backend.dll’: The specified module could not be found.)

#2

with due all respect, but it’s a happy new year for everybody. It wouldn’t look good for us to make it look like we’re ganging up on anybody. I provided a workaround for you with Virtualbox++ etc, and you kind of brushed that
 the admins will come here and be very upset that you’re re-posting.

just another user.

#3

Happy new year, ahms. I’m keeping it technical, and as you can see in the previous post, x42 replied asking me things, despite I was locked out. I am just providing the pertinent info I have. So, let’s keep this new thread technical and respectful :slight_smile: Off-topic chat not required.

Indeed, to me the virtualbox solution is not a viable path. I have issues with virtualbox. That’s why I did not consider it. But thanks for your suggestion.

#4

actually that’s inaccurate telling me the case because he was just correcting the fallacious statement earlier in the prior thread. The topic was regarded unsupported that’s why it was locked despite the unnecessary unfriendliness that was bestowed upon it.

The last two times you created a topic on this, the staff provided you with the best information they can, and you’re sort of making a little circus out of this by coming around to another round of a dead-ended discussion.

#5

Out of topic. Ahms, you are invited not to post flames in this thread and keep it technical. If you have anything meaningful to contribute, you are welcome. If you are not interested, just move away, thanks.

#6

2020-01-02_05-27
2020-01-02_05-271236×510 24.7 KB

#7

everything paul told you in october 2018, pretty much he repeated the same just 3 days ago. I mean really, who are we trying to fool here?

#8

Out of topic. Can you stop trolling this thread? Thanks

#9

When the staff feels disrespected, we users need to remind ourselves that we can support a project in various ways. I believe you’re only alienating the rest of us in being able to have a positive outreach when help is needed, so you’re not really using a voice for the rest of us like this. You’re really repeating this “name” thing again on here. I’ll digress and let staff take care of this kind of rudeness you’re playing on here.

#10

Ahms, what did you smoke? I have no rudeness in this post, I only wrote technical details.

x42 said I didn’t post enough information and suggested I do it like Guy Sherman. I obviously know his thread. So I just posted all the technical information I have. Simply contributing like others before me did. That’s it. It’s not me who came here to troll - read your posts. As I said, go flame (or smoke) somewhere else if you are not interested.

#11

@Ahms The devs will step in if they feel this post is out of line, please leave that job for them. Imho the devs welcomed discussion about the technical details of compilation on windows. Even though the devs don’t have time or resources to participate, other users might be interested or in the process of trying to solve the same problem. I feel the community gains something if aquilarubra manages to get compilation working and documented.

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