Gcc 11 on RL8.3 installed BUT no libstdc++.so.6 with GLIBCXX_3.4.29 - How to gen the gcc 11 dyn lib?

Rocky Linux Help & Support
1

Hi community.

I’m running RL8.3 and I’d like not to upgrade RL as it is stable as it is at the moment.

I’m struggling with a binary which is requesting GLIBCXX-3.4.29

Error is:

sc_dlopen failed: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.29’ not found

As https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html says, gcc 11 provides this 3.4.29 version:

GCC 11.1.0: GLIBCXX_3.4.29, CXXABI_1.3.13

So I installed gcc 11 on my RL8.3

I can run it in “scl enable” mode:

[adminbbo@localhost Public]$ sudo scl enable gcc-toolset-11 bash
[root@localhost Public]# gcc --version
gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@localhost Public]# g++ hello.cc -o hello.out
[root@localhost Public]# ldd hello.out 
	linux-vdso.so.1 (0x00007ffeae3f0000)
	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb3b0478000)
	libm.so.6 => /lib64/libm.so.6 (0x00007fb3b00f6000)
	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb3afede000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fb3afb08000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb3b080d000)

As you see, my gcc 11 binary relies on /lib64/libstdc++.so.6 dyn lib which is still the RL8.3 version (which is 6.0.25 and NOT the expected gcc 11 version 6.0.29)

In the gcc 11 context, I expected my compiled binary to rely on the gcc 11 version of libstdc++ which would be libstdc++.so.6.0.29 BUT I cannot find this dynamic library in the gcc 11 folder tree…

So my question is:
is there a way to have my gcc 11 generate the libstdc++.so.6.0.29 dynamic lib in order my failing binary to use this 6.0.29 version and not fail on the old 6.0.25 one?

Thank you very much in advance.

spoutnik

2

Alas, the only supported RL8 is currently (and to the EOL of RL8) the RL8.10.

If you did install from RL repo, then you did get gcc-toolset-11-gcc-c++-11.2.1-9.2.el8_9 – RL8.9 content.
If you did install from RL8.3 vault – well it had no gcc-toolset-11 at all.

In other words, you are not “sticking to RL8.3” and cherry-picking just some packages from “future” probably leads to more mess than dnf up.

That, however, is not your acute problem.

Which packages do have that “libstdc++” file? dnf provides */libstdc++.so.\*
Only versions of package libstdc++? Nothing in gcc-toolsets?

What does the currently installed package provide? rpm -q --provides -f /usr/lib64/libstdc++.so.6
Up to libstdc++.so.6(GLIBCXX_3.4.25)(64bit), doesn’ it?

Which packages provide that feature (rather than file)?
dnf provides 'libstdc++.so.6(GLIBCXX_3.4.25)(64bit)'
Only versions of ‘libstdc++’?

Which packages provide GLIBCXX_3.4.29?
dnf provides 'libstdc++.so.6(GLIBCXX_3.4.29)(64bit)'
“Error: No Matches found”

Nothing in RL seems to offer GLIBCXX_3.4.29 …

What does provide the libstdc++.so that GCC’s linker does use on compilation?
dnf provides */libstdc++.so
All the *libstdc++-devel packages, including those in gcc-toolsets.

However, the toolset versions are not symlinks to /usr/lib64/libstdc++.so.6, they are ASCII files, with something like:

/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf64-x86-64)
INPUT ( /usr/lib64/libstdc++.so.6 -lstdc++_nonshared )

That is, the toolset versions of GCC do link to the system /usr/lib64/libstdc++.so.6

You can follow the rabbit-hole of libstdc++_nonshared.a but wont find GLIBCXX in there either.

Summary, upstream GCC may provide never versions of GLIBCXX, but the gcc-toolset-11 in RL8 does make do with the libstdc++.so.6.0.29.

You have to find another distro or container to run that binary with, or (preferably) rebuild the application on RL8 so it will not require what RL8 does not have.

1 Like
3

Look at https://repo.almalinux.org/almalinux/8/SAP/x86_64/os/Packages/.

Download and install compat-sap-c++11-11.1.1-6.1.el8_9.x86_64.rpm. Then run your foo with:

$ LD_LIBRARY_PATH=/opt/rh/SAP/lib64 foo
4

Thank you for this.

This solved indeed part of the problem BUT I fell over another dependency issue:

sc_dlopen failed: /lib64/libc.so.6: version `GLIBC_2.32' not found

I believe this is a neverending story and I’ll look into another way to get this bin working on RL8, probably through re-compilation.

Thks.

5

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.