VCVRack
Minimum supported library versions for plugins
NYSTHI plugins currently do work on Ubuntu 16.04 LTS (see this issue reported back in December).
The error when loading plugins is as follows:
[warning] Failed to load library ./plugins/NYSTHI/plugin.so:
/usr/lib/x86_64-linux-gnu/libstdc++.so.6:
version `GLIBCXX_3.4.22' not found (required by ./plugins/NYSTHI/plugin.so)
Per the issue mentioned above, the Linux version of the plugin was compiled with Fedora 26, which has a newer compiler and supporting libraries than the current LTS version of Ubuntu 16.04.
Kent Williams provided a workaround on Facebook, which involved building a newer version of the compiler from source. This is not acceptable for non-developers. There also seems to be a workaround mentioned in the issue above that uses the custom LD_LIBRARY_PATH Rack sets up to load a newer version of the libstdc++.so.6.
I really don't like plugins relying on what I would call implementation-defined behavior of Rack to work (other recent example was some plugins relying on libsamplerate to be provided by Rack itself).
I understand the desire to not necessarily want to support oldold versions of Linux distributions, but could we define a minimum supported version of fundamental libraries for plugins that follows what Rack requires? Is this defined for Rack already?
We could punt and say that a "unified build system" (for example see #6) for all plugins would help solve this, but immediately, certain plugins are not working on all platforms. Cross-platform support is hard and plugin developers should be aware of those issues. Just jumping to the latest, greatest distros for development and requiring users to either upgrade or do other (worse) things does not seem to be a very user-friendly approach.
Thoughts?
There's a way to specify which libc and libstdc++ version to use. Let's do that. I've seen the method before---it's some weird linker declaration---and I don't know if it'll work, but someone should figure that out and I'll add it to the plugin build system.
The target libc version is 2.23, and the libstdc++ version is 5.4.0.
Let me see if I can state the problem: plugin developers must use 2.23 and 5.4.0 when building their plugins to ensure adherence to the minimum library requirements at runtime, correct? Since the libraries are forward compatible, building on Ubuntu 16.04 and running on Fedora 26 will work, but not the other way around.
The solution you mentioned above to provide a link flag that specifies the version to link to would provide a link error on stock Fedora 26 if the library is not available, which is desired. One would either have to provide the 2.23/5.4.0 libraries or use a system where the compiler provides those library version.
I looked into there does not seem to be straightforward and robust way to just specify "link to this version of libstdc++". Using rpath or assembly instructions do not seem feasible solution to me. There is a --with-glibc-version flag, but this does not work for g++ apparently.
Could the enforcement be done with a configure like step for plugins, which is run pre-make?
Not necessarily using autoconf, but check the environment for required library versions Rack defines before building the plugin. Or maybe a simple autoconf script would be OK for building on Linux?
Correct for first paragraph.
Note that version `GLIBCXX_3.4.22' not found is not a linker error but an error given by glibc++ itself after it is linked. It links just fine to the library, but the library does its own check and sets some backward compatibility mode depending on which version the application wants to link with.
asm is probably the way to go. I just haven't tested it on all OSes.
All autoconf does is eventually call shell commands. If they can do it, we can just call the shell commands.
Looking at that asm example, you would need to specify every symbol (realpath in that example) that needs to be linked against the older version? That does not seem feasible, unless I misunderstand that code.
autoconf: agreed. libc.so.6 is actually executable and prints out the version. libstdc++ requires it to be passed to strings command and greping for LIBCXX to get a list of supported versions. Not difficult and certainly does not require autoconf for just that.
Let me know if you need me to do anything else here. I can test Windows and Ubuntu 16.04.
Yeah, you're right that we'd have to rename every possible function. Not an option. Even with a shell script, renaming higher-versioned functions would probably break stuff.
Let's just call this a non-problem when everything is built from a centralized platform.
Fair enough. Until then, the convention for plugin developers could just be:
On Linux, build against the target libc version 2.23, and the libstdc++ version 5.4.0.
Maybe something worth mentioning in the Plugin Development Guide as a general guideline to have plugins follow the library requirements for Rack.
We only have one instance of this problem so far anyway (NYSTHI). Unfortunately, a package where source code is not available. So the developer should be convinced to be building against the minimum version of the libraries. Being able to point to an official convention on the website might make it easier for developers to understand.
I put together a simple script solution that will work for any Linux distribution, which supports Docker: vcv-plugin-builder-linux.
I'll see if the NYSTHI developer wants to give it a try on his Fedora 26 system. This will bridge the gap until the centralized platform is ready and is better than any of the workarounds, which put it on the user to change libraries on their system.