libc: Use the glibc 64bit time APIs to mitigate the Y2038 problem on 32bit platforms
The GNU libc (glibc) provides alternative 64bit entry points for many of the file and time related functions on 32bit platforms. For C programs these are activated by setting the -D_TIME_BITS=64 and -D_FILE_OFFSET_BITS=64 preprocessor flags. What happens is that all the relevant types (time_t, blksize_t, …) are defined as 64bit integers and the called symbols are redirected from the standard 32-bit variant like gmtime to a 64bit variant like __gmtime64.
In many ways this is the same as -D_LARGEFILE_SOURCE flag except that this will not add new types and symbols but replace the existing ones. Note that it is possible to use -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64 at the same time.
For full 64bit time support on llnux you also need a kernel newer than 5.6, but the 64bit glibc functions should be safe to use anyway and no worse than the 32bit versions.
The 64bit time support is needed when building embedded linux systems on 32bit platforms that are expected to live for 10 to 15 years.
About this issue
- Original URL
- State: open
- Created a year ago
- Reactions: 1
- Comments: 38 (19 by maintainers)
Note that Debian plans to switch to time64 for many 32-bit archs, but not for i386, according to wiki:
https://wiki.debian.org/ReleaseGoals/64bit-time
I’ll have a look at that later. I’m working on rebasing the PR right now.
If somebody needs something like crate libc, but without time32 and lfs problems, I suggest using crate rustix. You can read its code and see that rustix put a lot of effort to deal with time32 and lfs problems