From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44399 invoked by alias); 23 Jun 2016 16:56:16 -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 44388 invoked by uid 89); 23 Jun 2016 16:56:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=involving, shlib_compat, SHLIB_COMPAT, peculiarities X-HELO: relay1.mentorg.com Date: Thu, 23 Jun 2016 16:56:00 -0000 From: Joseph Myers To: Arnd Bergmann CC: , Albert ARIBAUD , Y2038 Subject: Re: Fourth draft of the Y2038 design document In-Reply-To: <19441244.1lHaNx8egQ@wuerfel> Message-ID: References: <20160622005838.60a95c44.albert.aribaud@3adev.fr> <4582546.7lC4NyOprV@wuerfel> <19441244.1lHaNx8egQ@wuerfel> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-06/txt/msg00931.txt.bz2 On Thu, 23 Jun 2016, Arnd Bergmann wrote: > Is there a policy about what justifies such an ABI break? I.e. is it The clear implication from the discussions around C++11 support in libstdc++, which resulted in the complicated ABI tag infrastructure, is that changing the libstdc++ SONAME would now be too costly, which implies the same for the libc SONAME. That is, incompatible ABIs may be introduced with new ports (including fundamentally different function-calling ABIs on an existing architecture), so under appropriate SHLIB_COMPAT conditionals, but we don't expect to make such changes on existing architectures (although as developers, it would be beneficial if we could change the libc and libstdc++ SONAMEs say once a decade and get rid of accumulated ABI peculiarities at that point - the problem is the effects of such transitions on users). > possible to add a build-time configuration flag later that disables > 32-bit time_t support for an existing architecture while setting > a different SONAME, assuming there is sufficient user interest for > this feature? I see a couple of different options that change SONAME > on https://sourceware.org/glibc/wiki/ABIList, but those are all > for fundamental incompatibilities, not for voluntary ABI breaks. We got rid of --enable-oldest-abi as being extremely bitrotten. I don't think new options for such incompatibility are likely, at least absent clear evidence of maintainability (and maybe builtbots using them, etc.). It is of course possible to use function lists developed in the course of designing and implementing _TIME_BITS=64 to produce a list of ABIs involving 32-bit time_t, which could be used to validate that a binary doesn't use such ABIs. And a configuration option to turn the symbols into compat symbols wouldn't break the ABI - it would be more like --enable-obsolete-rpc. -- Joseph S. Myers joseph@codesourcery.com