This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Fourth draft of the Y2038 design document
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Arnd Bergmann <arnd at arndb dot de>
- Cc: <libc-alpha at sourceware dot org>, Albert ARIBAUD <albert dot aribaud at 3adev dot fr>, Y2038 <y2038 at lists dot linaro dot org>
- Date: Thu, 23 Jun 2016 16:56:00 +0000
- Subject: Re: Fourth draft of the Y2038 design document
- Authentication-results: sourceware.org; auth=none
- References: <20160622005838 dot 60a95c44 dot albert dot aribaud at 3adev dot fr> <4582546 dot 7lC4NyOprV at wuerfel> <alpine dot DEB dot 2 dot 20 dot 1606231425220 dot 21240 at digraph dot polyomino dot org dot uk> <19441244 dot 1lHaNx8egQ at wuerfel>
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