Windows native compilation

Installation & Configuration Windows
#1

I might think to be a candidate for Windows support :slight_smile:

Anyway, this end of the year I am back at compiling Ardour on Windows natively, with mingw. I had complete success at compiling, so I made a webpage with all the steps to reproduce.

Now the issue is when the executable is launched. I see some errors that seem to imply some bug in the code. Before submitting bug requests, I thought to see here if somebody has some ideas.

Aside the window that says, “No audio/MIDI backends detected. Ardour cannot run (This is a build/packaging/system error. It should never happen.)”, I notice a few errors if I launch it from a DOS console:

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.)
Ardour: [INFO]: Loading default ui configuration file F:\a\usr\src\ardour6\share\ardour6\default_ui_config

Now, the no descriptor error seems to be a bug in the code. There was a similar issue with ladspa (https://github.com/sadko4u/lsp-plugins/issues/47).

After this, Ardour cannot read the following dlls, despite they are exactly there in the specified path. Thus, I guess that the first error impairs Ardour’s ability to see the following dlls, and then we have a catastrophic fault.

The backends are in the right path too, so they are also not seen.

I hope I can be useful, it was quite an effort to get Ardour compiled right. The native mingw port has the most updated packages and libraries, and it would be really nice to have a cutting edge Ardour.

2 Likes
#2

https://nightly.ardour.org/ can provide

#3

Nightly is not native, but cross-compiling. And anything that cannot be reproduced has no worth.

#4

We will likely never release a Windows build that was built on Windows.

And our Windows build system is completely reproduceable - we just don’t have the resources to hand-hold people through the process, or even to keep whatever documentation we have on it correct.

There are roughly 2.5 developers that work on Ardour - would you prefer them to work on bug fixes and feature development, or helping a tiny number of people who want to do their own Windows builds?

1 Like
#5

Linux in Virtualbox for the compilation I think the staff would be able to support, provided you’re relating to things that stick to whatever components that are related to the compilation itself and not about optimizing Virtualbox or its runtime.

The virtualbox would be better, because things like WSL change many things that could potentially affect the way compilation is done.

Once you have compiled ardour in the Vbox, there’s three ways to copy the build onto the host.

  • Vbox mountshare (see the VM settings for this, it’s basically a no brainer: The host becomes the “server” and the client needs to fire up a cifs:// or smb:// in Gnome nautilus, or alternatively a mount.cifs command to connect to the share)

    2019-12-30_23-36_1
    2019-12-30_23-36_1753×479 30.7 KB

  • fat32-on-usb copy – Essentially use a physical usb drive, and make sure there’s a fat32 partition available, and mount that in the guest, copy the windows build on to it, then use ‘Eject’ or umount from command-line. Then use one of the VM’s icons on the bottom-right to “unplug” the usb from the VM. Re-plugin the usb back in for the host to pick up and the windows build of ardour now becomes available.

    2019-12-30_23-36
    2019-12-30_23-36749×478 36.9 KB

    (Note: install Virtualbox Extensions Pack, so that you can enable USB2+ speeds, otherwise the copying will be slow at USB 1.1 which is the only supported speed when the extensions pack is not installed)
    (see virtualbox’s site on how to install it)

  • Use 7z to open the .vdi file like a traditional archive file. (read-write is not supported, only read-only). Navigate with the 7z tool and open the .vdi (disk image file), which is located in one of the VM paths on the host. Once the .vdi file is opened, navigate it like a file manager and locate the Windows build to extract it to the host. 7z is capable of extracting files from ext4 filesystems within the .vdi virtual disk image, so this should make things probably as the easiest solution available to you.

    https://sourceforge.net/p/sevenzip/discussion/45797/thread/1a1ec809/
    https://www.raymond.cc/blog/access-virtual-hard-disks-easily-in-windows-7/





#6

Paul, Ardour will always have 2.5 developers if you don’t accept contributions. Not everybody is here to prey on your source of revenue. I myself support Ardour’s model, but only till it becomes opaque. As I’m getting no support and find you guys bouncing back and never supportive, I - like others - feel the need to publish and straighten things up, and maybe even make a working fork of Ardour. Maybe there is a more friendly community somewhere else. Obviously, this would not be a good news for you, but that’s just the outcome of your attitude. Wrong way to defend your income. And you anyway state that a developer needs to go through the compilation process, which is just what I did, but you are just not open to accept new developers - even if they are at no charge.

My thought, after working a bit with Ardour and considering the lack of support, is that version 6 is not readily compatible in the format. A project that I saved with Ardour 5 was not usable in Ardour 6. But that was a year ago, so perhaps you fixed that. But this adds to the idea of instability and non retro compatibility of Ardour. Who wants to work, and loose all his work with next version?
Aside of that, the idea is that Ardour is bloat/crapware. It is obviously severely bloated with a ton of libraries and dependencies and doesn’t easily compile (aside your nightly, of course). This also does not add to the idea of a stable software.
I suggest you opt for another business model. Take musescore for example. You need to create added value, like a website where people can publish and share loops, libraries, etc. (this can be for sale too). See the strengths of Ardour and build on those. But issues with compilation, program obfuscation, bloating, only go against the product. I don’t mean to offend anyone, but just hope I can give new ideas and contribute.

Ahms, I think you mean cross-compiling on Linux. I did that too and succeeded. But at the end, mingw is Arch, so there is no issue with a native compilation. If some bugs come out, they can only help straightening the code and make the build more portable. With mingw on Windows it was fairly easy to compile. Issues come when running, but those definitely point to some issues in the code that need to be addressed.

Windows native compilation 2
#7

I have no idea what you are talking about. We accept contributions all the time. That’s why there are almost 80 developers in the Developer credits, and more in the translators list and more in the general contribution category. You don’t seem to understand who or what makes up the 2.5 developers I’ve referred to either. Hint: the 0.5 is not 1 person working half-time.

We are open to new developers, new PRs, new patches, new bug reports all the time.

Then there’s stuff like “A project that I saved with Ardour 5 was not usable in Ardour 6”. Ardour 6 has not even been released!! Every time you use it you are warned that it is unstable and not suitable for serious work. We take backwards compatibility seriously - every version of Ardour until now has been able to open sessions from every previous version (sometimes it will not be perfect because of fundamental changes in the application). It is outrageous that you would try to use the state of the current master branch for the basis of claims about Ardour 6, and even more so the state of that branch 1 year ago. We are hard at work dealing with the things that remain in the way of an alpha version of 6.0, and you show up and start whining about how a year ago, in the middle of massive architectural changes, it could not load a 5.x session? Unbelievable.

The point here is that you want something that we have no interest in: native Windows compilation as part of the build system. You are entirely welcome to implement this, and if it is done correctly, we’ll be happy to merge it. There’s already a guy who maintains the MSVC build - we want no direct part of it, but we’re willing to let him keep the various “project files” and whatnot up to date so that he use MSVC (for now, anyway).

What you are not welcome to do (other than wander in here with a pile of bullshit about what we do are open to and not open to) is to demand that we assist you with your goals. We understand that there are people for whom native compilation on Windows would be useful. That’s great! Go do it! It’s not useful to us, it’s not useful to the overwhelming majority of our users. If it happens, I’ll be glad to see it. But it is nowhere on our priority list, and we have way, way more than enough stuff on that list to even begin thinking about assisting with it.

#8

Paul, to reply politely but frankly, just look at your wallet and you will know what I am talking about. You may cheat everybody here with your predefined answers, but not me.
Ardour 6 is available as a development branch, or did you forget your git repository?

You say are not interested in a Windows build. But what is this?


https://nightly.ardour.org/
Quoting: " The Free/Demo version is gratis. It is fully-featured except that after 10min it will periodically go silent ".

That means you are VERY interested in Windows, as your money comes from there. And this is truly not the correct attitude in open source software anyway.

One thing I dislike is the different treatment people receive. For the same bug with ladspa, windows compilation, the thing was evaluated and solved at once (see posted link). When I propose something, I am turned down at once, as you obviously don’t know me. But there is no transparency, it is very clear you are hiding something.

But that said, you are entitled to whatever you want. I don’t judge you. You should just not think that everybody here is a noob. I find your non sense talk quite offensive. Go cheat someone else. I tried many times to contribute, but I was always dumped. So, the best thing is to branch and publish my fixes to the code there.

And by the way, the most stable Linux distro I ever worked with is Arch, which according to your standards would be a no go, as it is a cutting edge distro, which to many suggests that it may become unstable any time and is not tested enough. Well, but not everybody wants to live with old libraries (such as those you use to cross-compile Ardour v5 for Windows). I find that, especially in music, you absolutely need to have the latest development branch, to get the latest changes, even if you have to live with bugs. I also feel that old libraries will be EOL soon and might have more compilation issues than working with cutting edge libraries. Actually, I had to drop Debian a few years ago, just because some newer software could not compile. So, I just don’t want to work with technology that is 3-5 years old to the least. This is of course just my personal taste.

#9

At no point in the last 6 years or so have I (or anyone else) ever said that I am not interested in a Windows build.

Your definition of a Windows build is “a build that runs on Windows and was created on Windows”. That’s different from my definition, which is “a build that runs on Windows”. I think that’s the definition that the overwhelmng majority of our users care about.

Ardour 6 is NOT available as a development branch - it IS the master branch. I have no idea how anyone could have the idea that code that is:

  1. only available in a git repository
  2. when built generates a version ID of “Ardour-6.0-pre0.NNNN”,
  3. always shows a warning screen that it is an unstable version that should not be used

could ever be considered released. I never said that 6.0 was not available, I said that it is not released, and that anyone testing it should regard it in that way: an unreleased, unstable version of the code that we do not claim is finished or ready for use. That is why the warning screen says that at this time, we are not interested in bug reports. Does this mean we will never be interested in bug reports? Of course not. Once we reach alpha, we will be very interested in bug reports. But bug reports from last year? Certainly not.

I am hiding nothing. All our code, the entire financial situation, everything about what we do and who I am, is out in the open.

When I turn things down, it is not on the basis of who you are. If you show up tomorrow with a patch for the build system (and whatever else is needed) that enables native Window builds with mingw, that will be great.

You don’t seem to understand what the purpose of our build stack is. You are free to build Ardour on whatever Linux platform you want. Nobody is going to stop you from doing that (and indeed, during development, none of us are working (on Linux, at least) with the same versions as the build stack. But after 20 years of cross-platform development, we have learned a little bit about what is involved in releasing binary builds of software like this (the same lessons learned by Mozilla and others during the same period).

I’ve been involved in Linux kernel development. If you think I’m somehow harsh or dismissive, then clearly you have not had to deal with Linus and others within that community. Nothing that I’ve said has anything to do with anything about you personally. You want things that I consider at odds with our current goals. That’s all.

However, rather than just doing the work as so many of the other contributors to Ardour have done, you’re on here telling me things like:

  1. my attitude is not “correct” for open source
  2. that I consider everybody else a noob
  3. equating an unreleased under-development version of an application with a rolling release Linux distribution in an apparent attempt to say that I am clearly stupid
  4. claiming that I am hiding something
  5. misquoting my words to claim that I have said (recently) that I am not interested in a Windows build
  6. accusing me of cheating people

This is open source: instead of bitching, do the work. If you can’t do the work, find someone who can. If you want someone else to do some or all of the work, make a persuasive case that they should. That’s the way it always works.

You opened here by saying “I’ve gone through a process to build Ardour with mingw on Windows, but it hasn’t worked”. The implication was that you’d like help with that. I responded by saying that a native Windows build isn’t something we can put time or effort into, particularly not at this point. You apparently took this as a reason to start insulting myself and the project.

#10

Frankly, it seems you did not even took the time to read my posts and you continue to say non sense and change the meaning of my words.

Well, just live with your ideas, no problem by me. I posted in an ardour forum because it’s an ardour related topic. So, if the ardour team is not interested, it’s easier you simply don’t respond. Maybe someone else who reads and is interested may answer. We already know the answer of ardour devs, so it’s a waste of time for you to say always the same thing. I didn’t post to hear that. Respect

#11

@aquilarubra :baby_bottle:

:nerd_face:

#12

That is an incorrect assertion. That is the quoted statement can not be absolutely draw the conclusion you do. Your logic is flawed. At the current time, install files are provided for a number of platforms of which windows is one.
“not the correct attitude in open source software anyway”
Yes boss…

Again, an incorrect assertion. As you have already pointed out, it is all there on github, not hidden at all. It is also incorrect that “you were turned down”. rather this particular idea was turned down. That is because this idea does not help the Ardour community, it just takes a lot of work to satisfy your personal interpenetration of how something should be done while taking people’s work that could be put to better work elsewhere… like getting Ardour 6 to alpha.

You have, repeatedly.

Again you are putting words into other people’s mouth, do you actually think before typing? The problem with Arch is not stability. Ardour works to support the widest range of OS from win xp to the latest. It can best do so by using libs that are available on as many platforms as possible. The available install files do this very well the way they are. If a distro (like Arch) wishs to include Ardour as one of their packages, it is up to the packager to make it work. Ardour.org chasing Arch’s release pattern means Ardour would be stuck at version 5.12 forever. Or that the great number of people who do use debian would not be able to run it.

It does not matter, Ardour comes with the libs you need if the install file is downloaded. If you wish to build the system, then I am sure you can make newer libs work too. The idea of including needed libs has been around for decades in windows and is becoming quite common in Linux as well. (with flatpack and snap)

You have lost mine. Sorry.

#13

Frankly, this thread disappoints me. It doesn’t look good for the OP or the responders. This is all too personal, IMHO. I made mention of potential scenarios like this in a previous posting yet the ugliness is here for all to see. What happened to criticizing the idea and not the people (on both sides of the argument)?

#14

And of course you are correct.

At this point this thread is locked. Period.

  Seablade

EDIT Removed a comment I made that was not accurate, but point still stood.

#15
#16

Not you personally. The bug-report is closed, because it is invalid:
Ardour already has visibility macros for every library, so there is no bug to fix. Search for *visibility.h in the codebase. Also the referenced bug (LADSPA symbol visibility) was for Linux (not windows) and does not directly translate. – Ideally this would also have been posted on tracker.ardour.org

I lack the expertise to guide anyone through a native windows builds, so I cannot help you with the issue at hand.

Other people managed to compile Ardour natively on windows in the past, without any changes to the codebase (search the forum and web). So it is very likely that the issue is due to your setup. Even if we had the time and expertise to help you with all the steps to compile, the provided information is insufficient:
A walkthrough (like guy sherman did), that shows how this issue can be reproduced (setup, compiler and linker invocation, symbol listings etc,) would be useful for someone to point out where things went wrong, and eventually may also help others that would like to compile Ardour natively on Windows using mingw.