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.
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 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.
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.
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.
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.
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.
@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.
"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.
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/
@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…
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.
$ ./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
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.
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.
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.
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.
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?