Are there issues with replacing /usr/lib64/libstdc++.so.*

[Yegolev]

CentOS 7 of course comes with libstdc++.so.6.0.19 but we need something greater than 6.0.21. 6.0.25 is available in various places, and we have linked this in a dev system to good effect. Before we put this into production, I'd like to ask if there is some pitfall or danger in simply pointing the /usr/lib64/libstdc++.so.6 symlink to libstdc++.so.6.0.25?

[dunch]

Be careful, there be dragons. If you screw up the standard library, you can screw up the entire system. I'd look at installing elsewhere and using LD_LIBRARY_PATH or see if the version you want is in one of the devtoolsets and install that.

[TrevorH]

Yes. Don't do it. For a start, dropping in a new libstdc++ that doesn't belong to the distro could cause all sorts of ABI problems with existing things that depend on the current version. Next up, every time there is an update to the package that owns that file, it will replace it and adjust all the symlinks to point to the new copy.

If you want to see what might potentially be affected by this library replacement, try running yum remove libstdc++-4.8.5-36.el7_6.1.x86_64 and in about 10 minutes when it's finished scrolling past all the things it wants to take out with it, it'll tell you that it cannot do that because both yum and systemd are protected.

The correct solution is to rebuild whatever it is that requires the newer version against the things that CentOS 7 supplies.

[dunch]

devtoolset-6 has 6.3.1 if that'll do: https://www.softwarecollections.org/en/ ... toolset-6/

[hachi]

you can even have g++8, from devtoolset-8, which is nearly the latest version available
from the centos-sclo-sclo or centos-sclo-rh repository

[dunch]

The lesson here is never to let developers install whatever they want.

[Yegolev]

Thanks for all the replies, very helpful. While the correct solution may be to rebuild the application against 6.0.19, we are building the application against higher versions for a reason (don't ask me what those are, I don't have a PhD). For perhaps obvious reasons, we'd like to stick with CentOS instead of going "full-fedora".

We do have 6.0.25 (and .24) on the system but not linked at the system level. I did already ask about using those without linking the system into the mix, and I'd guess that is what we are going to end up doing since I don't see a way to go past 6.0.19 in a supported way.

I will, however, take a look at the SCLO repos.

Thanks again!

[dunch]

You don't need a PhD, you just need to know that developers like shiny stuff and don't care about stability or security or any of that boring stuff. On the plus side, if they're writing C++, at least they're not installing random npm modules from the Internet.

[hachi]

You don't need a PhD, you just need to know that developers like shiny stuff and don't care about stability or security or any of that boring stuff. On the plus side, if they're writing C++, at least they're not installing random npm modules from the Internet.

well, package managers for C++ are in discussion, and exists, see for example conan.io
however, I would like to ask you do not spread simplified generalisations, there are millions of developers in the world, at least some will not fulfil the stereotype you try to create here

[Yegolev]

The reasons are indeed very scientific and not at all to do with shiny new things, except where the non-shiny things do not provide a desired functionality. My reasons are very stability, but as you may have gathered I'm supporting the systems and not inventing scientific applications. So, I'm going to suggest not interfering with this .so while we are developing on CentOS 7.