我有两台服务器，其中一台运行 RHEL 7.4，另一台运行 CentOS 8，RHEL 带有 gcc 4.8.5 和 libc.so.6，2.17 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）构建的 3rd 方库（共享对象），我知道可能存在 ABI 问题，所以我认真对待并尝试在两台服务器上构建。结果令人惊讶，没有 D_GLIBCXX_USE_CXX11_ABI=0，CentOS 环境构建顺利，但 REHL 抱怨 /../linux64-demo/../../libs/LINUX64/libsomething.so: undefined引用 `std::ostream::operator<<(double)@GLIBCXX_3.4' 我认为这与 ABI 或链接错误的库有关，我尝试了使用和不使用标志 D_GLIBCXX_USE_CXX11_ABI，结果是一样的。
所以我做了字符串/dist/gcc/10.2.0/lib64/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 来解决这个问题？