Can’t open Vital in CentOS 8:
$ ./vital
./vital: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
Same problem in Fedora 33:
$ dnf provides libcurl-gnutls.so.4
Error: No Matches foundHi!
Congratulations for the release. Thanks for the great plugin!
(I was trying to buy the plus version through paypal but didn’t get through, but I will get to it, I promise!)
I am running on Fedora 33. I downloaded your Linux (ZIP) folder. When I try to run the ./vital executable however I run into the following issue:
./vital: error while loading shared libraries: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
Looking around I found that the problem is that Fedora links libcurl to openssl and not gnutls. I found the following workaround (although I know that doing that conjured the lord of hell himself):
# cd /usr/lib64
# ln libcurl.so.4 libcurl-gnutls.so.4
Then when I run vital it loads the interface. Yay us! It gives however the following console message:
./vital: /lib64/libcurl-gnutls.so.4: no version information available (required by ./vital)
And when I try to
login to access the presets and all the nice stuff I get An internal error has occured when clicking on Sign In.
Could we have a statically built version of vital for Linux so we don’t run into such issues as suggested in: Vital does not load in Ardour/Mixbus on Linux
Those bugs seem to be related.
Thanks greatly!
Edit: OP: Could you also add Fedora in the title? Thanks!
I’ve been seeing the same issue on Arch Linux with Bitwig.
Installing libcurl-gnutls allows me to use the standalone version and the lv2 plugin in Carla, but LV2 is not very commonly supported by DAWs. I think the no version information available is safe to ignore, as I get that in the standalone version.
On Bitwig plugin scanning at startup, I get the following error logged:
Failed to load VST2 plug-in Vital.so: libcurl-gnutls.so.4: cannot open shared object file: No such file or directory
Even though the file /usr/lib/libcurl-gnutls.so.4 does exist.
Interestingly, the VST3 plugin is scanned correctly, but crashes immediately when loaded into a track. I believe this is the only relevant plugin output logged:
Xlib: request 55 length 16 would exceed buffer size.
It’s been a longstanding dream of mine to finally be able to use Linux for music production, so I’d love to see these fixed - let me know if I can help in any other way.
FWIW, I second @eruyome’s request for a statically built version - from what I can see online the dynamic linking has been causing a good number of compatibility issues for others as well.
EDIT: After some discussion with others, I’ve learned that the current stable Bitwig version (I was running 3.2.4, but 3.2.8 is most recent as of time of writing) has some issues with VST plugins - upgrading to 3.3beta6 eliminates the libcurl-gnutls issue, although I get the Xlib: request 55 length 16 would exceed buffer size error during VST2 scanning now. Additionally, the VST3 version can load into a track successfully, but either becomes completely unresponsive or crashes shortly after opening the GUI. The relevant output is as follows:
[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
BitwigPluginHost64: xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
It’s a shame. I understand the .deb, but why the .zip package is Ubuntu-only?
@Kott plenty of programs are only available as Ubuntu builds, and then other distributions repackage them as necessary. For example, Bitwig only has .deb releases, and Arch Linux has AUR packages that extract the archive and use the binaries inside. The .zip in this case is a bonus, and there’s nothing fundamentally preventing the same binaries from running on other distributions, it just ends up needing some additional tweaking.
But, unlike the .deb release, dependencies must be resolved manually - which is why either a statically compiled version would be appreciated, as it would bypass the entire dependency issue.
By Ubuntu-only I mean libcurl-gnutls.so.4 linking against. And you said mostly the same - static linking, but it’s not so easy for JUCE plugins.
JUCE has JUCE_LOAD_CURL_SYMBOLS_LAZILY def https://github.com/juce-framework/JUCE/blob/df3b49fbd35655ed2530e77e005034d87987c765/modules/juce_core/juce_core.h#L143
at least it will allow running on other distros
i have the same problem
on a GENTOO linux
Same issue on Arch Linux:
vital: /usr/lib/libcurl-gnutls.so.4: no version information available (required by ./vital)
Install using the most recent pro .deb and a modified version of the vital-synth AUR PKGBUILD.
I realize only Ubuntu is officially supported, but any changes to make it run better on other common platforms would be greatly appreciated!
At least with the libcurl issue, it may be as simple as statically linking libcurl?
Regardless, thanks for making this available on Linux in the first place! That is huge, and bring me one step closer to being able to switch to Linux full-time for production.
You can get libcurl-gnutls rpm for Fedora 33 here:
https://copr.fedorainfracloud.org/coprs/patrickl/libcurl-gnutls/