问题描述
我有两台服务器，其中一台运行 RHEL 7.4，另一台运行 CentOS 8 RHEL 带有 gcc 4.8.5 和 libc.so.6 at 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 reference to `std::ostream::operator
所以我做到了 字符串/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，但具有相同的依赖项。
和OS自带的glibc有关系吗？我是否需要在 REHL 上构建一个新的 glibc，然后重新构建与新 glibc 链接的 GCC 来解决这个问题？
解决方法
经过整个周末的跟踪和错误，我发现这一切背后的原因是 因为操作系统自带的 binutils 老化了
我受到这篇文章的启发 https://unix.stackexchange.com/questions/596280/no-version-symbols-in-freshly-compiled-libstdc
只需构建一个更新版本的 binutils 并使用它来构建 gcc 10.2 即可解决所有这些问题。