Signed-off-by: Piotr Caban piotr@codeweavers.com --- I'm not sure if it's the best way of fixing the problem. I can't find anything else except of detecting time_t size at runtime.
dlls/ntdll/unix/sync.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)
On 4/22/22 07:29, Piotr Caban wrote:
Signed-off-by: Piotr Caban piotr@codeweavers.com
I'm not sure if it's the best way of fixing the problem. I can't find anything else except of detecting time_t size at runtime.
dlls/ntdll/unix/sync.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)
This will disable futexes if running under a kernel older than 5.1, though, which doesn't seem ideal. It should be relatively easy to keep the 32-bit wait as a fall-back path.
I also don't think we want to check __USE_TIME_BITS64, since that's an internal symbol.
I think it may be easiest just to manually define the timespec structure(s).
On 4/22/22 20:03, Zebediah Figura wrote:
On 4/22/22 07:29, Piotr Caban wrote:
Signed-off-by: Piotr Caban piotr@codeweavers.com
I'm not sure if it's the best way of fixing the problem. I can't find anything else except of detecting time_t size at runtime.
dlls/ntdll/unix/sync.c | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)
This will disable futexes if running under a kernel older than 5.1, though, which doesn't seem ideal. It should be relatively easy to keep the 32-bit wait as a fall-back path.
I also don't think we want to check __USE_TIME_BITS64, since that's an internal symbol.
I'm not sure if it's internal (name suggest it but glibc developers recommended to use it in kernel headers). A quick check shows one such usage.
I think it may be easiest just to manually define the timespec structure(s).
I don't think we should do it. While it will probably work in i386 only case it looks risky.
I've sent another patch that tries to solve it differently. It creates new file and undefines _TIME_BITS there. This should work if e.g. timespec size changes.
On 4/24/22 14:06, Piotr Caban wrote:
I think it may be easiest just to manually define the timespec structure(s).
I don't think we should do it. While it will probably work in i386 only case it looks risky.
I don't understand; why is it risky? It's part of the syscall ABI, so it should never change.
On 4/25/22 20:38, Zebediah Figura wrote:
On 4/24/22 14:06, Piotr Caban wrote:
I think it may be easiest just to manually define the timespec structure(s).
I don't think we should do it. While it will probably work in i386 only case it looks risky.
I don't understand; why is it risky? It's part of the syscall ABI, so it should never change.
My bad, I thought that the interface will change when _TIME_BITS=64 is enabled globally. I've sent fixed version.
Thanks, Piotr
-
Piotr Caban -
Piotr Caban -
Zebediah Figura