我有两台服务器，其中一台运行RHEL 7.4，另一台运行CentOS 8 RHEL附带gcc 4.8.5和2.17版本的libc.so.6 CentOS附带gcc 8.3.1和libc 2.28
我在两个服务器上构建了一个GCC 10.2，并安装到自定义的路径，如/dist/gcc/10.2.0，以构建GCC 10.2，我还构建了gmp 6.2.0，mpc 1.1.0和mpfr 4.0.2，这三个库也安装在我自定义的路径下，如/dist/gmp/6.2.0。
我在两个服务器上运行了很长一段时间都很顺利，我用我的全新GCC10.2在REHL和CentOS上构建了各种定制库。然而，上周我开始构建一个简单的C应用程序，它链接了第三方库（共享对象）使用旧gcc构建（可能是4.7 4.8），我知道可能会有ABI问题，所以我很认真地对待这个问题，并尝试在两个服务器上进行构建。结果令人惊讶，没有D_GLIBCXX_USE_CXX11_ABI=0，CentOS环境构建顺利，但REHL的一个抱怨类似/......./linux 64-demo/../../libs/LINUX 64/libsomething.so：未定义对'std：：ostream：：operator〈〈（double）@GLIBCXX_3.4'的引用，我认为这与ABI有关，或链接错误的库，我尝试了使用和不使用标志D_GLIBCXX_USE_CXX11_ABI，结果相同。
所以我用了字符串/dist/gcc/10.2.0/lib 64/libstdc.so.6| grep GLIBC“”“

GLIBCXX_3.4
GLIBCXX_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
GLIBC_2.3
GLIBC_2.2.5
GLIBC_2.14
GLIBC_2.4
GLIBC_2.3.2
GLIBCXX_DEBUG_MESSAGE_LENGTH

'''
我在REHL服务器上也做了同样的工作“”

GLIBC_2.2.5
GLIBC_2.3
GLIBC_2.14
GLIBC_2.6
GLIBC_2.4
GLIBC_2.16
GLIBC_2.17
GLIBC_2.3.2
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
__strtof_l@@GLIBC_2.2.5
symlink@@GLIBC_2.2.5
chdir@@GLIBC_2.2.5
fileno@@GLIBC_2.2.5
pthread_cond_destroy@@GLIBC_2.3.2
__strcoll_l@@GLIBC_2.2.5
__nl_langinfo_l@@GLIBC_2.2.5
dgettext@@GLIBC_2.2.5
fseeko64@@GLIBC_2.2.5
wmemcpy@@GLIBC_2.2.5
memset@@GLIBC_2.2.5
mbrtowc@@GLIBC_2.2.5
wcslen@@GLIBC_2.2.5
close@@GLIBC_2.2.5
__duplocale@@GLIBC_2.2.5
ioctl@@GLIBC_2.2.5
abort@@GLIBC_2.2.5
......

'''
看起来我在REHL上构建的libstdc++.so.6并不包含GLIBCXX3.4，即使两个主机都构建了具有相同依赖项的完全相同的GCC10.2.0。
这和操作系统附带的glibc有什么关系吗？我需要在REHL上构建一个更新的glibc，然后用新的glibc重建GCC链接来解决这个问题吗？