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