It seems that you are running Centos 7. When issuing the command strings /usr/lib/libstdc++.so.6 | grep GLIBCXX in Centos 7, it shows the following output:

GLIBCXX_3.4
_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_DEBUG_MESSAGE_LENGTH

This means that right now Centos doesn't support the version of glibc (, i.e., GLIBCXX_3.4.20) that is required by the latest version of Skype (v8.9).

If wish to install Skype in Centos at the moment, you can have a look at the nux repo which hosts a precompiled version of skype (probably an older version). Or you could always build the latest glibc from source and then try to install Skype.

If you're deploying on CentOS 7, build on CentOS 7.

Otherwise your runtime dependencies won't match up.

It's possible to ship your Ubuntu's libc and libstdc++ with your application, but you should avoid having to do this, if possible.

I ran into this same issue. I was able to use yum to download the RPM, then force install the rpm.

$ sudo yum install --downloadonly --downloaddir=/var/tmp/ libstdc++.i686
$ sudo rpm -ivh --force --nodeps /var/tmp/libstdc++-<VERSION>.i686.rpm

yum

--downloadonly - only download the package into an RPM

--downloaddir - download an RPM to the specified dir

rpm

--ivh - install/verbose log/print hashes for progress

--force - ignore existing installs, this is what ignores the above error

--nodeps - ignore dependencies

Try running yum provides libstdc++ to show you what package provided the library on your system. You can then check if those packages are available for update using yum list available | grep <that package> followed by yum update <that package>.

Commentary on YUM & deps

YUM does do this. But it's only as good as the RPM specifies. In this case your RPM states that it'll work with any GLIBC > 2.13 but it clearly was built with a specific version of GLIBC, and will only work if the appropriate GCC symbols are available on the system:

$ rpm -qpR trillian-6.1.0.5-1.fc25.x86_64.rpm
atkmm >= 2.22.0
cairo >= 1.12.0
cairomm >= 1.10.0
gdk-pixbuf2 >= 2.26.0
glib2 >= 2.30.0
glibc >= 2.13
glibmm24 >= 2.32.0
gtk3 >= 3.4.0
gtkmm30 >= 3.4.0
libX11 >= 1.5.0
libXScrnSaver >= 1.2.0
libnotify >= 0.7.5
librsvg2-tools >= 2.36.0
libsigc++20 >= 2.2.10
libzip >= 0.10.0
openssl-libs >= 1:1.0.1
pango >= 1.30.0
pangomm >= 2.28.0
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
zlib >= 1.2.0

You can use rpm -qpR <rpm> to determine what dependencies it requires.

More on your issue

The heart of your issue is you're attempting to use a package that was built using a different version of the GCC compiler vs. what run time libraries are actually available on your OS.

In your case you're on CentOS 7.x and you really cannot mix RPMs across Fedora & CentOS like this, or at least you shouldn't.

If you look at what package owns that shared library:

$ rpm -qf /lib64/libstdc++.so.6
libstdc++-4.8.5-28.el7_5.1.x86_64

You can also investigate the shared library itself to see what GCC symbols it supports:

$ nm -D /lib64/libstdc++.so.6 | grep -i GLIBC | head -5
0000000000000000 A GLIBCXX_3.4
0000000000000000 A GLIBCXX_3.4.1
0000000000000000 A GLIBCXX_3.4.10
0000000000000000 A GLIBCXX_3.4.11
0000000000000000 A GLIBCXX_3.4.12

And finally look to see if it includes the ones that this RPM's binaries is looking for:

$ nm -D /lib64/libstdc++.so.6 | grep -iE '3\.4\.20|3\.4\.21'
$

No surprises here, this .so library doesn't include the symbols for either of those versions of GCC, hence the error.

What to do?

The typical ways you deal with this are either:

1. Get a binary built against your GCC's symbol definitions

2. Get just the libstdc++.so.6 library from some other tool (many apps opt to include libraries for easier deployment/setup/installation) and point to it via your LD_LIBRARY_PATH. You typically do it like this:

   $ LD_LIBRARY_PATH=/path/to/lib trillian
   

3. Run the app in a VM

4. Run the app in a Docker container
5. Get a version of the RPM that has binaries that were built using symbols that are consistent with your OS's GCC setup.

Given the similarities between Fedora & CentOS I've had good success with many of the above. You could try #5, and try one of the older Fedora RPMs on their website to see if it was built with CentOS's version of GCC symbols.

References

• https://en.wikipedia.org/wiki/GNU_C_Library
• How To Write Shared Libraries
• Static, Shared Dynamic and Loadable Linux Libraries

Your application MCServer was compiled and linked with different g++ than current for your OS, and ABI is not compatible. You either need to find libstdc++.so.6 for original compiler and set environment variable LD_LIBRARY_PATH accordingly or recompile the app with compiler, that comes with your OS.