Re: Y2038 - best way forward in Debian?
On Wed, Feb 12, 2020 at 11:15 PM Steve McIntyre <steve@einval.com> wrote:
> Simon McVittie wrote:
> >On Tue, 04 Feb 2020 at 13:14:10 +0000, Steve McIntyre wrote:
> >> Arnd scanned the library packages in the Debian archive and identified
> >> that about one third of our library packages would need rebuilding
> >> (and tracking) to make a (recursive) transition.
> >
> >Is a list of affected/unaffected packages available? (I know they'll
> >be long lists.) Depending on how high up the stack they are, the right
> >approach might change.
>
> I don't have the list, I'm afraid. Arnd?
I lost both the script and its output after a crash unfortunately, but some
of it was captured in a mailing list post at
https://www.openwall.com/lists/musl/2019/07/02/2
It took me about a day to download all the -dev packages and scan through
the header files for known issues (time_t, struct timeval, struct timespec,
struct stat, struct timex), but it should not be hard to reproduce what
I did then.
The list obviously has both false positives (struct names in the headers
but not actually part of the ABI), and false negatives (indirect ABI changes
resulting from other types), but it's a good first approximation.
> >Thinking about i386 specifically, since the tradeoffs for that architecture
> >are likely to be a little different due to the prevalence of proprietary
> >binaries, the use-cases I am aware of are:
> >
> >- Old hardware that doesn't implement amd64.
> > Breaking ABI would help here, but equally, this use-case seems likely
> > to go away "naturally" in the next 10? years (and for example Ubuntu is
> > already relegating i386 to a second-class-citizen status as a multiarch
> > library stack on amd64 systems, with no kernel or full bootable OS).
> >
> >- amd64-capable machines that have inherited a legacy i386 installation
> > because their owner doesn't want to reinstall or sidegrade to amd64.
> > Breaking the i386 ABI seems like it would be counterproductive here:
> > they'll still need to reinstall or sidegrade, and sidegrading from
> > i386 to i386t would probably be very crash-prone, since those will
> > presumably both have to be represented by ELF32 x86 binaries?
> >
> >- 32-bit Wine (to run 32-bit Windows programs).
> > On the Unix side, breaking ABI would maybe help. On the Windows side,
> > Wine needs to match whatever Microsoft does to solve this problem
> > (apparently time_t already defaults to 64-bit on Windows, but older
> > binaries will presumably use 32-bit time_t forever).
>
> Hmmm. I didn't think Microsoft used *time_t* as such, but had their
> own 64-bit format based on an epoch in ~1600?
Both the C standard and POSIX require time_t, so they do define one
with the POSIX semantics, but it's not that common and they changed
it to 64 bit a long time ago. Note that 'long' is also 32 bit on Win64,
so this was probably more urgent for them.
The 1600 (1604 IIRC) based epoch is used in NTFS, not sure where else.
> >- Running old proprietary or otherwise sourceless binaries (e.g. games).
> > Breaking ABI is counterproductive: we can't recompile the games anyway.
> > Some solutions for running these (e.g. the Steam Runtime used by Steam)
> > rely on host libraries being approximately ABI-compatible with the ones
> > the binaries were compiled against, because they need to fetch graphics
> > drivers and their dependencies from the host system, otherwise they
> > could not work on recent GPUs (although by 2038, with faster CPUs, we'll
> > hopefully be able to run 2010s games at acceptable performance with
> > software rendering like llvmpipe, which would sidestep this issue).
> > (See the slides/video from my recent FOSDEM talk for more details)
>
> ACK. I'm in agreement here. I also personally don't see the same
> benefit to doing a 64-bit time_t transition for i386, using any of the
> models we've suggested. It's a legacy ABI that we should explicitly
> warn people will break. Have the Steam folks considered this issue at
> all yet, OOC?
I suspect for any particular software package, it should be fairly
straightforward to address the time64 conversion by inspecting
the libraries that are actually linked in, presumably steam is dealing
with dozens of dependencies, but not thousands of them that you
would see for a complete Debian port.
Similarly, Ubuntu and Redhat only ship a limited number of 32-bit
libraries these days, and that number may be shrinking further,
to the point where an exhaustive review of the interfaces makes
sense. For any particular library, there is probably a way to use
symbol versioning or some macro based abstraction to have it support
both time32 and time64 interfaces in the same binary.
Arnd
Reply to: