Centos 7, I thought “yum install ___” was supposed to get all the dependencies, too

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