From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21283 invoked by alias); 19 Jun 2018 12:18:42 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 21269 invoked by uid 89); 19 Jun 2018 12:18:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=arbitrarily, accessible X-HELO: relay1.mentorg.com Date: Tue, 19 Jun 2018 12:18:00 -0000 From: Joseph Myers To: Carlos O'Donell CC: Florian Weimer , , Subject: Re: Future of libio vtable compatibility In-Reply-To: Message-ID: References: <87h8m41oa0.fsf@mid.deneb.enyo.de> <3a215566-1748-a095-8bfa-c5c1d5017156@redhat.com> <874li0uig3.fsf@mid.deneb.enyo.de> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-ClientProxiedBy: svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-SW-Source: 2018-06/txt/msg00555.txt.bz2 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 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