Not working on Linux: Libraries are not statically linked

There’s a trend towards delivering all files with the installation to avoid problems just like this. Ubuntu has Snap while other distros favor Appimage and Flatpak.

I think most users will be happy to get a working binary and won’t complain about statically linked libraries.

@Tytel I think it’s only frowned upon with open source software that becomes part of a distribution’s repository, because then the package is compiled by the maintainers and guaranteed to work with the system libraries.

With proprietary software, like Vital, the work of making the app compatible across all distributions befalls the developer exclusively. Helm is open source, which might be why you haven’t experienced this friction before.

I understand that there can be a few cons to open sourcing Vital. It’s no trivial task to be the maintainer of a code base which is subject to endless scrutiny, unsolicited patches and change requests. But at least issues like this could easily be solved by the community. Just a thought.

1 Like

Most commercial software only supports Ubuntu officially, and everyone else has to figure out how to get them to work.

You can’t expect a developer to support 5 or more distributions that are responsible for less than 5% (and that’s generous) of their revenue.

Personally, I’m happy to have a Linux version at all, and I’m not going to make any demands to have it open sourced.

Besides, even with open source apps, you’re usually months or even years behind the current release in your distribution. That’s why Snap et al exist now.

If the downloads page said “Ubuntu” and not “Linux”, and I hadn’t paid 80$ for it, I’d agree, but it says Linux and I’m a paying customer.

It’s well within the realm of reason for me to request that Vital works on other popular distros, when I know the solution isn’t too complex to pull off either. Besides, it would only be good for business if it worked everywhere.

If you use Ubuntu and it works on your system, good for you. This bug report doesn’t affect you.

This bug report affects me because I’m using Manjaro and I have to click to get past the login screen every time.

But I’m able to read, so I saw that only Ubuntu is supported on the sales page, so I don’t make irrational demands. The download page also says Windows, but you wouldn’t expect it to run on XP, would you?

It also affects me because dev time is limited and if it is spent on supporting hundreds of distributions, less features will be developed as a result.

I think the supported OS should be stated more clearly. If it does not work on some versions of Windows, this should be stated, similarly for Linux and MacOS. Also which platforms are supported, e.g. Ubuntu x64 is supported but not x32, arm, etc. I feel it a fair request to make the supported systems clear on the sales / download page. I also would like to see minimum system requirements listed.

With regard to supporting other platforms or distros, that may need to wait until there are developer, testing, release resources available. (It isn’t available on any platforms I currently run :slightly_frowning_face: .) One can’t expect more than 24 hours in any one day :smile:.

I don’t know how it could be any clearer

Okay, yeah, maybe it could be a little clearer :sweat_smile:

But at least it says Ubuntu, just not which CPU architectures.

Generally, it’s a good idea to download the demo to see if it works or not. It’s impossible to predict compatibility with all the hard and software combinations out there.

For the issue at hand, that won’t help. There is a conflict with the libraries that Ardour/Mixbus binaries use. Specifically /opt/Ardour-*/lib/
System-wide also depends on glib, but require a different version of it.

@tytel: What does Vital use on Windows and macOS instead of libsecret?

Many GNU/Linux distributions do not want to re-link all applications when a shared library changes. It makes perfect sense for standalone applications, but plugins are special. In fact they should always be statically linked (except for libc, libX11, and lib/server interfaces), and not expose symbols. KXStudio for example statically links all plugins.

This is so that plugins cannot conflict between each other.

Tech Details

Say you have one plugin linking against system-wide and another using They have conflicting APIs so many distros still bundle both for applications to use them. But when loading the plugins there will be a symbol conflict. Same for libavresample, or QT4/Qt5…

By induction this also include the host (which may use libraries), but the host is a singleton.

To avoid ABI conflicts, the only option other than statically linking is to process-separate plugins (like Carla does). But many hosts (incl. Ardour) do not do that:


What @x42 writes is probably the reason why vital as a plugin does not work for me (and others) in Ardour 6.3 on supported Ubuntu 20.4.

Same for me on Linux Mint 20.1 (derivative of Ubuntu 20.04). Hope to see this fixed soon in order to be able to work with VItal in Ardour / Mixbus…

Ah this is pretty useful, thanks. I’ll have to revisit this when I’m tweaking the builds.

Mac and windows both have some included things like libsecret in the OS. Vital uses the keychain on Mac but I can’t remember what I’m using on Windows.


Any update on the Linux builds? I just bought Vital Plus and can’t load it in Ardour 6 on Ubuntu 20.10.

In any case, great work. I also purchased Helm. It’s really user-friendly.

Sorry if this is a bit of a necro.

I’m on Fedora 34, and Vital wasn’t working for me due to the libcurl-gnutls issue, but I found a COPR package for it, and now Vital works. However, sign-in doesn’t work at all. It could be related, but it doesn’t give any output in the console.

Static linking would be really nice for compatibility, if it’s not much trouble

Same issue on fedora 35, cannot get vital to work cannot open shared object file: No such file or directory

1 Like

@Tytel i think the best way to support other Linux Distros is to ship a Flatpak version. Currently exist all most all Audio Plugins as Flatpak also you Helm Synth is already as Flatpak version available :smiley:
A Vitalium Version exist also aready as Flatpak Version but unfortenly it have a strange bug but maybe we can figureout it together.

pls checkout this Link:

I still searching for the Helm Github link but i cant find it i just know it exists and works greate AS flatpak

Sorry to resurrect this old thread.

@Tytel Hi Matt, I’d love to work with Vital in Ardour on Linux, I wonder if you had time to look at the issue of statically link libsecret-1 within the Vital VST … Thanks again.


This is orthogonal to the issue at hand, it’s just a different means of distribution.

While you could include the relevant shared libraries in the flatpak, there will still be conflicts once loaded into the host where the ABI can conflict with other plugin or host libraries.

So either the plugin needs to be statically linked, or compiled with the same dependency stack as other plugins.

1 Like

Yea ok i think static linking is the best solution U-He dose this also and works perfect on all Distros i used :slight_smile: As a workaround on Fedora i currently using Vitalium

1 Like

It seems that the new beta pre-release (1.5.1) solved the library conflicts in Linux and now Vital loads fine in Ardour. Thanks @Tytel

1 Like