Minimum supported library versions for plugins about library HOT 10 CLOSED

Updated post with correct version and package info

from library.

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.

from library.

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.

from library.

OK. I'll look into that and test with some Docker images.

from library.

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?

from library.

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.

from library.

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.

from library.

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.

from library.

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.

from library.

Closing since the https://github.com/VCVRack/rack-plugin-toolchain was designed to build plugins that run on systems with minimum libc/libstdc++ versions.

from library.