On Mon, Jan 15, 2024, at 16:46, Antonios Salios wrote: > On Thu, 2023-12-21 at 14:38 +0100, Antonios Salios wrote: >> On Thu, 2023-12-21 at 12:28 +0000, Arnd Bergmann wrote: >> > On Thu, Dec 21, 2023, at 08:56, Antonios Salios wrote: >> > > On Tue, 2023-12-19 at 13:53 +0000, Arnd Bergmann wrote: >> > > > On Tue, Dec 19, 2023, at 02:50, Dmitry Torokhov wrote: >> > >> > I don't know what __TIMESIZE is, this is not part of the kernel ABI >> > as far as I can tell. __USE_TIME_BITS64 should be set by any 32-bit >> > architecture if the C library defines a 64-bit time_t, otherwise >> > the >> > kernel headers have no way of picking the correct definitions based >> > on preprocessor logic. >> >> Okay, I agree that this might be a libc problem then. I'll ask the >> glibc maintainers. >> > > According to a glibc maintainer, __USE_TIME_BITS64 is not set on > architectures that use 64-bit time_t as default such as riscv32. > This can also be seen here [1]. > > Perhaps the kernel header needs to check the size of time_t in some > other way? > > [1] > https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/features-time64.h;hb=glibc-2.37 I don't see any better way, the kernel headers started using this in 2018 based on the glibc design documents and discussions with glibc maintainers, see the section on ioctls in https://sourceware.org/glibc/wiki/Y2038ProofnessDesign The kernel only relies on this macro for the sound and input subsystem, but there are numerous applications and libraries that copied the kernel definition because that was defined as the only reliable method. Maybe you can work around by patching the glibc sources yourself? Arnd
