Anyway, the resulting artifacts appear to be linked with system default version of libstdc++:
Yes. The devtoolset-6-gcc-c++ package provides a custom version of GCC that uses a special linker script instead of a dynamic library for libstdc++.so. That means the binaries it produces do not depend on the newer libstdc++.so.6 and can be run on other CentOS machines that don't have devtoolset installed (i.e. they only have the older libstdc++ library from GCC 4.8).
Is this build environment configuration valid?
Yes. What you're seeing is completely normal, and how it's supposed to work.
The pieces of the newer C++ runtime from GCC 6.4.0 get statically linked into your binary, and at runtime it only depends on the old libstdc++.so which every CentOS system has installed.
That's the whole point of the devtoolset version of GCC.
Answer from Jonathan Wakely on Stack Overflowc++ - Pointing to libstdc++ from devtoolset - software collection - Stack Overflow
Possibly wrong link order / devtoolset-8 libstdc++ unknown symbols
gcc - C++ project compiled with modern compiler, but linked against outdated libstdc++ - Stack Overflow
CentOS: Using GCC 4.7 from devtoolset results in linking libstdc++ incorrectly (undefined symbols) - Stack Overflow
the final binary is missing some symbols
That looks like a bug in devtoolset-1-gcc, which I assume has been fixed in more recent versions of devtoolset.
Interestingly, the libstdc++ from devtoolset links agains to the old one:
Yes, that's how the devtoolset gcc is supposed to work (see this answer for more details).
What I actually want is to replace the libstdc++ binding, but I don't know how to achieve that.
You can't do that with the devtoolset of GCC, because it doesn't even have a new libstdc++.so library. As you found, that file is actually a linker script, which links your binary to libstdc++_nonshared.a /usr/lib64/libstdc++.so
Since there is no new libstdc++.so you can't link to it.
The GCC compiler and its libraries (very specially g++ and corresponding libstdc++ runtime) need to match. Compiling with a newer compiler will (very often, practically guaranteed if a new version of the language is supported) give binaries that don't work with an older library. Older binaries might work with a newer library, no guarantees here.
I found a solution here: https://www.linuxquestions.org/questions/red-hat-31/lib-libstdc-so-6-version-%60glibcxx_3-4-15'-not-found-4175419985/
Replacing libstdc++-so.6 with a later version that works in EL6: Unpack libstdc++6_4.7.1-2_i386.deb http://ftp.de.debian.org/debian/pool...7.1-2_i386.deb with : ar -x libstdc++6_4.7.1-2_i386.deb && tar xvf data.tar.gz Next : 1) su ; 2) cp libstdc++.so.6.0.17 /usr/lib/ 3) cd /usr/lib/ && rm libstdc++.so.6 4) ln -s libstdc++.so.6.17 libstdc++.so.6
Reason for suggesting the Debian package : It's a ( gcc ) libstdc++ version that's compiled with a glibc old enough to be used in EL6 / CentOS 6.
Updated steps (because it seems the file has been moved):
curl -O http://ftp.de.debian.org/debian/pool/main/g/gcc-4.7/libstdc++6-4.7-dbg_4.7.2-5_i386.deb
tar -x libstdc++6-4.7-dbg_4.7.2-5_i386.deb && tar xvf data.tar.gz
mkdir backup
cp /usr/lib/libstdc++.so* backup/
cp ./usr/lib/i386-linux-gnu/debug/libstdc++.so.6.0.17 /usr/lib
ln -s libstdc++.so.6.0.17 libstdc++.so.6
On Linux the dependency on system compilers have always been frustrating since it means your stuck with ancient GCC versions. But I must say I'm very impressed with devtoolset for RHEL/CentOS, it means you can use gcc-7 on old crappy RHEL6 that so many large companies insist on using. And you can ship the resulting binaries and it will run on plain vanilla RHEL installations!
what is devtoolset ?
devtoolset-7 also provides newer versions of lots of supporting debug and performance tools like gdb.
They (RH or Centos) also provide containerised versions of the build tools and the performance tools.
There is also a tech preview of the llvm-toolset, admittedly at clang v4 but still able to build those compatible binaries.
Note that you want to build using a host that is lower or same version as your minimum target version.
e.g. toolset-7 on host centos v6.7 will create bins compatible with 6.7, 6.9 and 7.x If your host is say centos 7.2 toolset-7 builds are only guaranteed to be compatible with v7.2+ targets.
Redhat's documentation is really good (and you can even get a free developer login to access more resources).
Also note that Centos provides similar options to RHEL.
The only downside is I don't think you can use the new ABI variant of CXX LIB as the ABI isn't compatible with older compilers like the default Centos gcc 4
Not really a problem as you can still use the C++11/14/17 features, just a few items are incompatible (such as list::size() still being O(n) and not const time, or strings still being COW)
https://www.softwarecollections.org/en/scls/rhscl/devtoolset-7/ (Lots of other tools/langs etc there too like Go,Rust,Python3 and lots of database updated versions etc.)
Not sure if you need to have a developer account, but an example of the documentation: https://access.redhat.com/documentation/en-us/red_hat_developer_toolset/7/html/7.0_release_notes/dts7.0_release