skip to Main Content

I have two servers one of which is running RHEL 7.4 and the other one is CentOS 8
the RHEL comes with gcc 4.8.5 and libc.so.6 at 2.17
the CentOS comes with gcc 8.3.1 and libc 2.28

I built a GCC 10.2 on both server and install to customized path something like /dist/gcc/10.2.0
to built the GCC 10.2, I also built gmp 6.2.0, mpc 1.1.0 and mpfr 4.0.2, those three libs are also install under my customized path like /dist/gmp/6.2.0..

things has been smooth on both servers for a long time, I built all kinds of customized library on both REHL and CentOS with my brand new GCC10.2.
However last week I started to build a simple C++ application which links a 3rd party lib( shared object) built with old gcc(4.7 4.8 likely), I know there could be ABI issues so I took that seriously and tried building on both servers.
The result is surprising, without D_GLIBCXX_USE_CXX11_ABI=0, CentOS environment builds smoothly
but the REHL one complains with something like /……./linux64-demo/../../libs/LINUX64/libsomething.so: undefined reference to `std::ostream::operator<<(double)@GLIBCXX_3.4′ which I believe has something to do with ABI, or linking wrong lib, I tried both with and without flag D_GLIBCXX_USE_CXX11_ABI, the result is same.

So I did
strings /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

”’

and I did the same on the REHL server
”’

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
......

”’

it looks like the libstdc++.so.6 I built on REHL does not contain GLIBCXX3.4
even thou both hosts were building the exact same GCC10.2.0 with same dependencies.

Does it have anything to do with the glibc that comes with the OS? Do I need to build a newer glibc on REHL and then rebuild GCC linking with the new glibc to solve this?

2

Answers


  1. Chosen as BEST ANSWER

    after a whole weekend trail and error, I found that the reason behind all these is because of the aging binutils that comes with the OS

    I was inspired by this post https://unix.stackexchange.com/questions/596280/no-version-symbols-in-freshly-compiled-libstdc

    simply build a newer version binutils and use that to build the gcc 10.2 solves all these problems.


  2. This worked for me on CentOS Stream 8. (originally not from me)

    To Check:

    • strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search