Question

3

Why is a 21.10 built binary not compatible with 21.04 install?

rated 0 times [ 3] [ 0] / answers: 1 / hits: 4215 / 3 Years ago, thu, may 27, 2021, 5:18:59

I don't understand why a binary built on 21.10 is not compatible with an 21.04 system.

The binary is linked against libc.so.6 which is available on the 21.04 OS version as well.

Same binary, on the 21.10 system:

$ ldd turboledzd

    linux-vdso.so.1 (0x00007ffdc2595000)

    libhidapi-hidraw.so.0 => /lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 (0x00007fdd64057000)

    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdd63e2f000)

    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007fdd63e06000)

    /lib64/ld-linux-x86-64.so.2 (0x00007fdd64085000)

And on the 21.04 system:

$ ldd turboledzd 

./turboledzd: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./turboledzd)

    linux-vdso.so.1 (0x00007fff9c570000)

    libhidapi-hidraw.so.0 => /lib/x86_64-linux-gnu/libhidapi-hidraw.so.0 (0x00007f37ec402000)

    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f37ec216000)

    libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x00007f37ec1ed000)

    /lib64/ld-linux-x86-64.so.2 (0x00007f37ec423000)

    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f37ec1cb000)

My question:

If libc.so.6 from 21.04 is not compatible with libc.so.6 from 21.10, then why isn't the libc on 21.10 called libc.so.7 instead?

Or, better, why is it not linked against something called libglibc.so.2.34 - if that is a dependency?

Answers

Only authorized users can answer the question. Please sign in first, or register a free account.

rontablis

Add To Favorites

Follow

Total Points: 293

Total Questions: 123

Total Answers: 104

Location: Austria

Member since Mon, Mar 1, 2021

3 Years ago

rontablis questions

1 How to solve "No Wi-Fi Adapter Found" error with Realtek RTL8852BE WiFi 6 802.11ax PCIe in Ubuntu 22.04?

Fri, Dec 10, 21, 15:20, 2 Years ago

1 Replacing Pulseaudio with Pipewire in Ubuntu 20.04

Wed, Oct 26, 22, 13:48, 2 Years ago

1 apt update and Ubuntu Software get stuck

Thu, Aug 12, 21, 01:52, 3 Years ago

1 I have problems with bluetooth mouse and bluetooth headphones simultanously in Ubuntu 20.04

Sat, Jul 9, 22, 17:34, 2 Years ago

1 Cache Refresh Stuck At 100%

Thu, Jan 19, 23, 14:01, 1 Year ago

View All

answered 3 Years ago mocipe · Accepted Answer

The term to google for is "glibc symbol versioning".

As this introduction explains, glibc contains multiple versions of each symbol that has changed over time and so libc.so.6 contains all glibc versions from 2.0 through to whatever version it says.

When you link a new library or binary against it, you're using the .h files and exported symbols for the newest versions of the symbols.

As for accessing the older symbols, there's a question over on StackOverflow named How can I link to a specific glibc version?, but because all your other dependencies are likely to be linking against the newest symbols too, it's much easier to just use Docker or a chroot to target older system versions because you'll probably wind up building one from scratch if you don't.

The Python devs actually maintain Docker containers named manylinux... specifically for establishing a reliable baseline for building wheels (redistributable binary packages) for Python packages with compiled components.

I believe the Windows approach is closer to bundling multiple clearly defined profiles and urging all authors of precompiled libraries to offer builds targeting older profiles. (With the caveat that you have to assume that stuff must be freed by the same compilation unit that malloc'd it because PE doesn't have global symbols and different libraries may depend on different versions of the allocator with their own static variables and semantic differences.)