CODEWITHSUNDEEP
gccg++libstdc++
cynric4sure
cynric4sure

Reputation: 199

GLIBCXX not found in local built libstdc++.so.6 GCC10.2.0 on REHL7.4 and CentOS8

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?

Upvotes: 1

Views: 1470

Answers (2)

ARK
ARK

Reputation: 1

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

To Check:

  • strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

Upvotes: 0

cynric4sure
cynric4sure

Reputation: 199

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.

Upvotes: 0

Related Questions