[Development] Help requested: 32-bit and the year 2038
Lisandro Damián Nicanor Pérez Meyer
perezmeyer at gmail.com
Fri Feb 3 14:16:36 CET 2023
El martes, 31 de enero de 2023 21:31:55 -03 usted escribió:
> El martes, 31 de enero de 2023 20:21:47 -03 Thiago Macieira escribió:
> > On Tuesday, 31 January 2023 15:00:07 PST Thiago Macieira wrote:
> > > As most of you are aware, a signed 32-bit time_t overflows in 2038.
> > > Linux
> > > has recently deployed "time64_t" (by certain values of "recently", as in
> > > 2015, see )
> > >
> > > I don't know if this is an emulation bug. It's likely.
> > Ah, it looks like the kernel side of this didn't get merged until Linux
> > 5.1
> > (2019), with commit 48166e6ea47d23984f0b481ca199250e1ce0730a. A quick look
> > at QEMU sources shows it did get support for those system calls in 2020.
> > That means that the QEMU in the Ubuntu 20.04 in the CI is probably too old
> > to emulate the system call.
> > While I will be asking for an update in the infra there, that brings the
> > question up: is it acceptable to require Linux 5.1 or later for 32-bit
> > deployments of Qt? If not for 6.6, when would it be?
> > If it's not going to be in the near future, I *can* modify the patch to
> > detect that the new system call is not implemented and then fall back to
> > the old one. That would mean that every contended mutex or semaphore will
> > incur two system calls instead of 1 on Linux 5.0 or older (which I find
> > acceptable; just upgrade to regain performance).
> > Let me know what the community prefers. I don't have an opinion.
> Some data:
> - Debian 10 "buster", currently oldstable, has 5.10.
My apologies, that seems ot be only in special cases. It's bullseye , Debian
11 and current stable the one shipping a kernel >= 5.1.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Development