这是一个 Linux c++ 程序，编译和部署均在 centOS 7.9/gcc 4.8.5 的环境上。这个程序需要对接多种证券交易柜台提供的交易 sdk （头文件和动态库），这些动态库大多是 gcc 4.8.5 编译出来的。根据 cmake 配置，程序在编译期决定最终链接哪种交易 sdk 的动态库，完成编译链接。也就是说，虽然要适配多种 sdk ，但实际上运行期只加载了某一家的动态库。

基于 gcc 4.8.5 ，只能使用 c++11 ，如果想使用 c++14/17 ，那么可能需要考虑在高版本发行版中编译程序，同时打包对应的 gcc 相关的动态库。我的理解是二进制程序所需的动态库依赖的 glibc 可能与 centos 7.9 提供的不符。那么这个场景下，可以考虑 rhel/centos 提供的 devtoolset ，他们使用的是当前发行版提供的 glibc 。

devtoolset 9/10/11 提供了高版本的 gcc ，支持了 c++11/14/17 ，使用的也是发行版对应的 glibc 。但是 libstdc++.so 呢？在询问 ai 时，提到的方案就是说把 devtoolset 提供的 libstdc++.so 和二进制程序打包部署，设置 library rpath 来加载。我考虑说，如果我使用的是 devtoolset 中提供的 libstdc++.so ，那么程序在运行时加载的就是这个版本的，又会与交易 sdk 的动态库所需的版本不符，可能会产生问题。ai 也说是这么个理儿。我就放弃了使用 c++14/17 的念头。

但是我今天想起这个事情，又想折腾一下，我发现 ai 提到 devtoolset-9 的 libstdc++.so.6 在 /opt/rh/devtoolset-9/root/usr/lib64，我在这个目录下面根本没翻到 libstdc++.so.6 ，而是翻到了 /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++.so，这玩意儿不是动态库，而是个 ASCII text ，内容如下：

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
INPUT ( /usr/lib64/libstdc++.so.6 -lstdc++_nonshared )

也就是说，实际上 devtoolset 并不提供 libstdc++.so ，而是使用的发行版默认的；同时通过 /opt/rh/devtoolset-9/root/usr/lib/gcc/x86_64-redhat-linux/9/libstdc++_nonshared.a 来补充高版本 c++ 标准库所需的实现？

那我是不是可以通过 devtoolset 来使用 c++14/17 ，同时链接 centos 7.9 提供的 libstdc++.so.6 给二进制程序和交易 sdk 动态库使用，不需要担心冲突问题，顶多在用个 GLIBCXX_USE_CXX11_ABI 来处理问题？