[Development] Help requested: 32-bit and the year 2038

[Lisandro Damián Nicanor Pérez Meyer]

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 [1])
> > > 
> > > 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230203/e9aaec44/attachment.sig>