How can I resolve this issue: libm.so.6: version `GLIBC

When I've tried to execute my C demo app on RPI CM4, app that was cross compiled on Ubuntu OS:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.04.1 LTS
Release:    20.04
Codename:   focal

This is my errors from RPI:

root@rpi-cm4:/home/pi# ./demoApp
./demoApp: /lib/arm-linux-gnueabihf/libm.so.6: version `GLIBC_2.29' not found (required by ./demoApp)
./demoApp: /lib/arm-linux-gnueabihf/libstdc  .so.6: version `GLIBCXX_3.4.26' not found (required by ./demoApp)

Some info's about my RPI:

# lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:        10
Codename:       buster

# uname -a
Linux rpi-cm4 5.15.65-v7l  #1582 SMP Mon Sep 5 15:34:37 BST 2022 armv7l GNU/Linux

# ldd --version
ldd (Debian GLIBC 2.28-10 rpi1) 2.28


# ldd --verbose /lib/arm-linux-gnueabihf/libm.so.6
        linux-vdso.so.1 (0xbefe7000)
        /usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0xb6e4d000)
        libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xb6cec000)
        /lib/ld-linux-armhf.so.3 (0xb6ee4000)

        Version information:
        /lib/arm-linux-gnueabihf/libm.so.6:
                ld-linux-armhf.so.3 (GLIBC_2.4) => /lib/ld-linux-armhf.so.3
                libc.so.6 (GLIBC_PRIVATE) => /lib/arm-linux-gnueabihf/libc.so.6
                libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
        /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so:
                libc.so.6 (GLIBC_2.4) => /lib/arm-linux-gnueabihf/libc.so.6
        /lib/arm-linux-gnueabihf/libc.so.6:
                ld-linux-armhf.so.3 (GLIBC_2.4) => /lib/ld-linux-armhf.so.3
                ld-linux-armhf.so.3 (GLIBC_PRIVATE) => /lib/ld-linux-armhf.so.3

How can I make a GLIBC update?

CodePudding user response：

You can try to download the glibc from their official website and install it:

wget -4c https://ftp.gnu.org/gnu/glibc/glibc-2.29.tar.gz
tar -zxvf glibc-2.29.tar.gz
cd glibc-2.29
./configure --prefix=/opt/glibc
make
make install

CodePudding user response：

If you have the application's sources, simply proceed as advised by @jakob-stark in the comments.

I've run into a case a while ago where I had a mismatch between the glibc the executable was built against (v2.35) and the one available in the target OS (v2.31). The problem, in that case, was that it involved a closed source executable but, luckily, no extra dependencies. I had no other choice than voiding many warranties.

This solution will supply the app's required version of the glibc, without breaking the vital parts of the OS for the other managed apps.

Disclaimer: this is a pain.

Here is how I solved that problem:

On the target OS, I've installed pre-built packages or compiled the requirements: wget, gcc, gawk, bison, patchelf and make.
Retrieved the desired glibc sources, required by the application:

wget https://ftp.gnu.org/gnu/glibc/glibc-2.35.tar.gz

Extracted the tarball, and created a build directory:

tar xzf glibc-2.35.tar.gz && mkdir glibc-2.35/build && cd glibc-2.35/build

Built it for later install in a place that doesn't hurt the one shipped with the target OS:

../configure --prefix=/opt/glibc-2.35 && make -j`nproc` && sudo make install

Created a backup of the original app, just in case:

cp /path/to/demoApp{,.bak}

And now the trick that solved everything by patching the problematic ELF using patchelf:

patchelf --set-interpreter /opt/glibc-2.35/lib/ld-linux-armhf.so.3 --set-rpath /opt/glibc-2.35 /path/to/demoApp

This solution worked great for my use case. Hopefully this solution will also be helpful in similar use cases.