Not working on Linux: Libraries are not statically linked

This issue has already been mentioned here and here

I’m creating a new topic anyway, since I purchased the bundle that would supposedly prioritise topics I create.

My setup is Fedora 33 with Ardour/MixBus.

The errors I get when running the LV2 are:

/lib/x86_64-linux-gnu/libsecret-1.so.0: undefined symbol: g_input_stream_read_all_finish

and

/usr/lib/lv2/Vital.lv2/Vital.so: /usr/lib/libcurl-gnutls.so.4: no version information available (required by /usr/lib/lv2/Vital.lv2/Vital.so)

I can symlink the libcurl library like this…

sudo ln -s /usr/lib64/libcurl.so.4 /usr/lib64/libcurl-gnutls.so.4

…but I have no workaround for libsecret, and it shouldn’t be necessary anyway.

Statically linked libraries is an absolute must for Linux, it’s the best way to make apps compatible across distros.

@Tytel is this change something we can expect soon, since it’s a “blocker” issue? I understand the amount of bug reports might be a little crazy right now, so I’d understand perfectly if this would take a while. As long as it gets done, I’m a happy customer :slight_smile:

3 Likes

I have the same issues and the same environment, subscriber too. When you link the libcurl Ardour opens the plugin? How about the formats LV2, VST3?

No, the workaround only gets me past the first error and onto the next one.

VST and LV2 both exhibit the same behaviours.

I think the issue is that this plugin was only tested on Ubuntu, but the downloads page says “Linux”, so I expect that Vital was intended to work across distros, just like Helm does.

Yeah I’d like to support other distros (only officially supporting Ubuntu distros atm) and make things install cleaner but I didn’t have the time before release. I’m going to expand support to other distros but need to look into things like this.

I’ll see about statically linking a few things but I thought that was frowned upon.
libsecret is to remember login credentials which lets you auto download presets and make text to wavetable requests but I’ll see about making that optional.

Anyway yeah I’ll get to these kind of improvements and expand support down the line once things are stable in ‘officially supported’ systems.

4 Likes

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/libglib-2.0.so.0.
System-wide libsecret-1.so.0 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 libaubio.so.2 and another using libaubio.so.3. 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: https://ardour.org/plugins-in-process.html

7 Likes

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.

1 Like

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.