VCV Rack has its own libzstd, for which all symbols need to be visible as it is part of the whole Rack SDK.
Issue is that system library libzstd is required for new mesa (opensource GL drivers), and this version is not ABI/API compatible with the one provided by Rack.
When GL operations take place on some linux systems, the userspace side of the graphics driver will call some libzstd functions. Typically the system lib would be used, but since Rack has its own built-in libzstd, the built-in version is used instead. Unless both built-in and system versions are made to match, we can expect issues.
To put it in example generic terms:
let’s say a host uses libfoo.so.2 while a plugin uses libfoo.so.1, where internal ABI details changed from v1 to v2.
When this host loads the plugin that uses old libfoo.so.1, plugin actually will call libfoo.so.2 stuff.
This becomes undefined behaviour, and crashes are not unexpected.
Rack is the plugin in this example.
I see a few possible solutions:
- update libzstd to latest (bad one, will get into the same issue later on again)
- run the whole Rack out of process, so host vs plugin symbols no longer clash (has performance impact)
- place all libzstd calls under its own custom namespace (requires new Rack release and rebuilding all plugins)