GLIBCXX version in RHEL7

I don’t expect much in the way of support, since I’m using a janky version of Linux (Centos7) , but…

I am running on Centos7 (which is the free version of Red Hat Enterprise Linux 7 LTE) and there’s a perennial problem with loading plugins made with a different version of Linux (i.e. with a newer version of the compiler).

I built using the GCC7 toolset (which you can optionally use on Centos) to build Rack and that was fine, but it only finds the VCV modules, and the plugin manager stays lit red, because of linkage problems with the plugin shared objects:

[0.004 warn src/plugin.cpp:147] Could not load plugin User/plugins-v1/AmalgamatedHarmonics: Failed to load library User/plugins-v1/AmalgamatedHarmonics/plugin.so: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21’ not found (required by User/plugins-v1/AmalgamatedHarmonics/plugin.so)

I see both the GLIBCXX_3.4.21 and GLIBCXX_3.4.20 symbols as being undefined/required, so the plugin manager packages aren’t built consistently either.

This was solved for 0.6 – the question is this: will it be solved in 1.0, or are older Linux distros just deprecated?

What is the version of your libstdc++6 package?

The highest version number mentioned in /lib64/libstdc++.so.6.0.19 is 3.4.19

The odd thing is that I’m using GCC7 and it’s still compiling to link against /lib64/libstdc++.so.6. Given the environment setup in the scl script, I’d think it would link to the newer version defined when you turn on the gcc7 toolset.

I also tried adding -static-libgcc -staticlibstdc++ to the compile flags for Rack, and that seemed to introduce a different set of shared object load problems.

BTW Thanks for looking into this, as I imagine your hands are full at this point. I may not be the only person running an older version of Linux but it’s probably not a huge number of people!