how do I remove `GLIBC_2.27' requirement at compile time?
Asked Answered
A

3

6

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
Application answered 7/3, 2019 at 16:29 Comment(1)
I did find this to be instructive: sourceware.org/glibc/wiki/Testing/BuildsApplication
S
5

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.

Sit answered 25/4, 2019 at 11:54 Comment(1)
That glibc_versoin_header is fantastic!Application
R
2

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

Rokach answered 7/3, 2019 at 19:13 Comment(3)
Yes, but how do I tell the compiler what glibc version to build with?Application
At present, the only practical way is to use an older distribution (at least as old as the eventual target).Rokach
I've learned that you can use the --sysroot parameter to tell the compiler which library foundation to utilize. It does look somewhat involved, and is probably not worth the effort.Application
C
1

Try symbol versioning, e.g.:

__asm__(".symver old_foo,foo@VERS_1.1");

Related question: Fedora 28 / GLIBC 2.27 libm.so.6 logf() and powf() c++

Corallite answered 12/12, 2019 at 7:9 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.