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?
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!
Well it’s my own GCC8 build. You can build Rack with older compilers – or use the system-wide GCC7 package that you can enable when you need it. But basically you need a newish version of libstdc++.so.6 and libgcc.so.6 and it needs to be before the system directories in LD_LIBRARY_PATH.
It has something to do with my bashrc resetting LD_LIBRARY_PATH when it runs Rack. I could fix it if I did a deep dive but I got it working a different way & I can’t be arsed to fix ir “right.”
A perennial problem, thanks to versioning symbols. Like @chaircrusher, I discovered that the LD_LIBRARY_PATH dodge in the Rack Makefile no longer works for make run, I just get this error, regardless which libstdc++so.6 I try.
[0.046 warn src/plugin.cpp:156] Could not load plugin ./plugins/NYSTHI: Failed to load library ./plugins/NYSTHI/plugin.so: /lib64/libstdc++.so.6: versionGLIBCXX_3.4.22’ not found (required by ./plugins/NYSTHI/plugin.so)`
Open to suggestions. I know I need to upgrade but this system is otherwise a smooth running gun.
One thing you could do is make and install the latest gcc & g++ – if you install them into the standard system paths, it will update your libstdc++.so (and libgcc.so)
Since I’m assuming you have sudo privilege on your machine.
This will replace the default system compiler, but that won’t matter unless you e.g. build your own kernels.
