Re: Future of libio vtable compatibility

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 18 Jun 2018, Carlos O'Donell wrote:

> I also do not think we need to line up dozens of ABI breaking changes
> to make glibc 3.0 valuable. For example in glibc 3.0 we can drop all
> of the libio vtable compat, and get DJ's patch in to remove the
> malloc hooks (which now use a distinct prelodable library). Call it
> done. Then in glibc 4.0 we might unify all the libraries into one
> if that's what we decide.

I don't think this subjective notion of what is or is not a major change 
is a suitable basis for changing the version number.  (After all, unifying 
all libraries into one would presumably be done in a fully compatible way 
that keeps usages such as dlopen of libm.so.6, and dlsym having opened 
such a library, and linking with -lm, -lpthread etc., and existing 
binaries, working.  Anything it breaks would probably be similar to code 
doing dlopen of libm.so as opposed to LIBM_SO from gnu/lib-names.h, which 
we already broke by making libm.so into a linker script.)

I think changing the major version number should correspond to a SONAME 
change on at least one platform (and even for the case of changing SONAME 
for some but not all platforms, it's unclear if the major version should 
change).

This is not an objection to any particular proposal for some change that 
might have compatibility concerns (though I've already said we should 
provide the alternative preloadable library to keep mtrace working before 
doing anything that would stop it working with the default libc), just to 
arbitrarily saying some such change, that doesn't change SONAME for libc, 
should make it glibc 3.0.

I also think it's clear that future changes that obsolete a symbol version 
and provide a new version of the same symbol with some incompatible 
changes need to add tests for the obsoleted symbol to make sure it 
continues to behave as expected (both general behavior and the specific 
differences between the versions), given the difficulty we're having with 
telling exactly what does or doesn't work for both vtable compatibility 
and C programs linked with glibc 2.0 using the old FILE objects.  (That's 
not needed in the trivial case where the semantics of the new symbol are a 
refinement of the semantics of the old one, so the new version is only 
provided to stop new binaries running incorrectly with old libraries and 
the two versions are aliases - for example, when the return types of 
fenv.h functions changed from void to int in C99 TC1.)  Adhemerval, this 
means I think your fcntl64 patch adding a new version of fcntl on 32-bit 
platforms should also have tests for the old compat version of fcntl.

Ideally we'd add such tests for past compat symbol versions, but in 
practice we have so many non-compat public symbols lacking test coverage - 
see scripts at 
<https://sourceware.org/ml/libc-alpha/2013-07/msg00386.html> to find such 
symbols - and adding tests of such symbols accessible to new programs is 
generally more valuable, and probably less effort, than adding tests of 
compat symbols.

-- 
Joseph S. Myers
joseph@codesourcery.com