I've been using a docker image for c++ compilation. It's based on Ubuntu 18.04. When I attempt to run on some Ubuntu 16 systems, I get this message:
/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found
I'll post the full ldd output below. I like using the newer compiler. I would prefer to not compile with an older Linux base image (but I will if necessary). I statically link most libraries, but I haven't been statically linking glibc. A number of web sources recommend against that. Is there some way I can tell my newer compiler (gcc 7.3) to not require the newer glibc? ldd -v output:
linux-vdso.so.1 (0x00007ffd167cf000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007eff77399000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007eff77191000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007eff76df3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007eff76bdb000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007eff767ea000)
/lib64/ld-linux-x86-64.so.2 (0x00007eff79f90000)
Version information:
lbrycrd-linux (4)/lbrycrdd:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
librt.so.1 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/librt.so.1
libm.so.6 (GLIBC_2.27) => /lib/x86_64-linux-gnu/libm.so.6
libm.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libm.so.6
libgcc_s.so.1 (GCC_3.3) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libgcc_s.so.1 (GCC_3.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libgcc_s.so.1 (GCC_4.2.0) => /lib/x86_64-linux-gnu/libgcc_s.so.1
libpthread.so.0 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.3) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 (GLIBC_2.15) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.9) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.10) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libpthread.so.0:
ld-linux-x86-64.so.2 (GLIBC_2.2.5) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/librt.so.1:
libpthread.so.0 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libpthread.so.0
libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libm.so.6:
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libgcc_s.so.1:
libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6
/lib/x86_64-linux-gnu/libc.so.6:
ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2
ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2
So, in a way, we can have multiple versions of glibc on our machine and have a libglib-2.0.so link to a specific version. The linker will look for the soname field in the shared object and embed it in the resulting binary. The soname field specifies the filename for our target shared library.
The current stable version of glibc is 2.36, released on August 1st, 2022. The current development version of glibc is 2.37, releasing on or around February 1st, 2023.
I faced the same problem.
/lib/i386-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by your_lib.so)
After searching over the internet, I found some links that could be useful.
Static link: Link with -static. See How can I link to a specific glibc version?
Using docker: See Can docker solve a problem of mismatched C shared libraries?
Proprietary solution: See https://github.com/wheybags/glibc_version_header
I have decided to follow the first one. So I created a static library for your_lib.so and linked it statically with my binary.
You need to build against an older glibc version. Very few distributions, if any, support that out of the box. The only practical way at the moment is to build on an older distribution.
Some distributions with long support cycles offer newer GCC versions that do not require newer system compilers (such as Developer Toolset, which is available for CentOS and Red Hat Enterprise Linux).
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With