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

Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail.com
Wed Feb 1 01:31:55 CET 2023

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.
- For a Variscite VAR-SOM-MX8M-NANO SoM the [wiki] lists Yocto Zeus as the 
first BSP with a kernel >= 5.1. According to the [Yocto releases] page that's 
behind two LTS releases. And the board is 64-bit capable, but anyways...

I would say Qt 6.6 could easily require a kernel >= 5.1. Of course if someone 
has data saying otherwise...

[wiki] <https://variwiki.com/index.php?title=VAR-SOM-MX8M-NANO>
[Yocto releases] <https://wiki.yoctoproject.org/wiki/Releases>
-------------- 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/20230131/e046b8c2/attachment.sig>

More information about the Development mailing list