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>
signature.asc
Description: This is a digitally signed message part.
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development