I’ve been seeing the same issue on Arch Linux with Bitwig.
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.