[Bug libc/24636] Export basic metadata about ABI compatibility

["joseph at codesourcery dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=24636

--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
On Fri, 7 Jun 2019, njs at pobox dot com wrote:

> Let's imagine a hypothetical 2.40 that turns out to have urgent bugs, so we end
> up with a 2.40.1 release that includes some @GLIBC_2.41 symbols.

In that case I expect we'd use @GLIBC_2.40.1 instead.

> This would be different from --enable-oldest-abi, because it wouldn't be
> configurable at build time; it'd just be taking whatever decision you'd made
> about abi compatibility, and making it more visible to the rest of us. And it's
> different from changing the minimum symbol version, because it doesn't refer to
> symbols, it refers to binaries built against those old versions. So bumping the
> min_runtime_abi to, say, 3, would just mean "if a binary was built against
> glibc 2.2 or earlier, we no longer guarantee that it works".

But that's simply not how slightly-incompatible changes work in practice.  
It's not generally removing features that might only be used by binaries 
built with a given glibc version.  It's removing features that might only 
be used by C++ binaries built with GCC 2.95 or earlier, for example 
(independent of the glibc version they were built with).  Or removing 
features that might be used by binaries built with any glibc version, but 
are sufficiently obscure we think that is unlikely to be relevant in 
practice - take the recent discussion of the copy_file_range emulation for 
older kernels, for example; that would be removing a feature 
"copy_file_range sometimes works without ENOSYS on older kernels".

Because there is no total ordering for such features and no relation in 
general to particular old glibc versions, a minimum ABI can't really be 
defined in a way that could usefully change to reflect such 
slightly-incompatible changes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.