The ABI status of ELF hash tables

Posted Aug 20, 2022 3:46 UTC (Sat) by WolfWings (subscriber, #56790)
Parent article: The ABI status of ELF hash tables

This is not the only 'breaking' change GNU LibC did in recent updates. the 2.34 change to the initialization routines in a "it's not complete but we're pushing it to production" step of merging most historically separate libraries into a single one means anything compiled on a recent distro can't run on older distro's anymore.

And since it's a change to how __libc_start_main behaves in a way that explicitly breaks being run on older linkers (because of course they had to make it feed a NULL where a valid value used to be) you can't just patch around it at compile time either.

Also as noted, the SysV ABI standard requires DT_HASH so they're out of compliance by NOT including it. Supporting not adding it is one thing, but just yeeting it by default definitely is not a good play.

The ABI status of ELF hash tables

Posted Aug 20, 2022 10:44 UTC (Sat) by pbonzini (subscriber, #60935) [Link]

> anything compiled on a recent distro can't run on older distro's anymore

That has always been true if you used a symbol that had a redefinition in newer versions of glibc. It just happened rarely.

The ABI status of ELF hash tables

Posted Aug 20, 2022 12:03 UTC (Sat) by khim (subscriber, #9252) [Link] (4 responses)

> anything compiled on a recent distro can't run on older distro's anymore.

This was never considered a breaking change and shouldn't be considered a breaking change. All others types of libc have the exact some issue and that was never promised by anyone.

If you want to run binary on older system you have to use older libc. It's as simple as that.

In Linux world that's provided by RedHat for RHEL, but not by other distributions, while on macOS and Windows old versions of libc are included in standard developer's package, but that's not a glibc fault.

The ABI status of ELF hash tables

Posted Aug 21, 2022 6:52 UTC (Sun) by comex (subscriber, #71521) [Link]

At least on macOS, there is no shipping of old versions of libc. Instead, there's a compiler flag to explicitly declare the minimum OS version you want the binary you're compiling to run on. Each function declared in OS header files includes a minimum OS version, and attempting to use an API that's too new is a compilation error. In situations like the mentioned one, where the ABI for existing APIs changes (such that newer OSes can run old binaries but not the reverse), the header files, or sometimes the compiler or linker itself, will pick the old or new ABI depending on the same declared minimum OS version.

That said, Xcode does eventually drop support for targeting old OS versions; the current lowest minimum-OS option is 10.9 from 2013.

The ABI status of ELF hash tables

Posted Aug 27, 2022 21:36 UTC (Sat) by WolfWings (subscriber, #56790) [Link]

To clarify, this is the first time I'm aware of that such a change landed that can't simply be aliased around by tacking an older version of a given function into your codebase, or even in most cases simply aliased to the old version.

They've never done a breaking change at the startup libc functions before.

The ABI status of ELF hash tables

Posted Aug 28, 2022 21:04 UTC (Sun) by HenrikH (subscriber, #31152) [Link] (1 responses)

>If you want to run binary on older system you have to use older libc. It's as simple as that.
Or you compile the binary for the old symbol with the new glibc, since glibc contains versioned symbols including all the old ones you can tell the linker exactly which version of the function that your binary wants to use. So while it is a real pain it can be done.

The ABI status of ELF hash tables

Posted Aug 29, 2022 8:56 UTC (Mon) by Wol (subscriber, #4433) [Link]

Can you do that if it's a binary you don't have source for?

Eg I've got a libc5 binary I would love to run, but it was a commercial product ...

Cheers,
Wol