GLIBCXX 3.4.15 on Centos 6

I would consider this a hack but have used it on more occasions than I care to admit to get around compatibility issues with GLIBC, such as the one you're encountering.

The hack involves making a link in /usr/lib which includes the name of the library that a particular tool wants. The link then points to alternative name of the library.

Example

Say I wanted to create a link to libstdc++.so.6.

$ ls -l /usr/lib | grep libstdc++.so
lrwxrwxrwx.  1 root root       19 Dec 18  2010 libstdc++.so.6 -> libstdc++.so.6.0.14
-rwxr-xr-x   1 root root   950428 Sep 24  2010 libstdc++.so.6.0.14

It works out be something like this:

$ ln -s libstdc++.so.6 libstdc++.so.6.0.15

Checking the results:

$ ls -l /usr/lib | grep libstdc++.so
lrwxrwxrwx.  1 root root       19 Dec 18  2010 libstdc++.so.6 -> libstdc++.so.6.0.14
lrwxrwxrwx.  1 root root       19 Dec 18  2010 libstdc++.so.6.0.15 -> libstdc++.so.6.0.14
-rwxr-xr-x   1 root root   950428 Sep 24  2010 libstdc++.so.6.0.14

But I'm not sure this method will work since you're library will still be missing the version string, GLIBCXX_3.4.15.

If the hack is unsuccessful then you'll likely have to bite the bullet and install GLIBC in an alternative directory, and then override LD_LIBRARY_PATH or LD_PRELOAD so that the execution of just steam sees the modified library.

Example

$ LD_PRELOAD='mylibc.so anotherlib.so' program

Details on how to do this are covered a bit more here in this SO Q&A: Multiple glibc libraries on a single host.

Basically the version of the libstdc++ RPM package shipped by CentOS (4.4.7) is not recent enough for your application. CentOS offers longterm stability instead of the latest and the greatest versions, so that's not completely unexpected.

Fedora is normally quite a bit ahead and may run your server without any issues.

Alternatively you could build a newer version of libstdc++ from a more current source. I would start off the CentOS SPEC file in the gcc SRPM , the latest release from gcc.gnu.org and rework those to build my own RPM's.

Upgrades of C libraries were in the past a good way to break a system in unexpected ways though...