Year 2038 problem (_TIME_BITS=64...)

[pobrn]

I haven't found any discussions about this, so I would like to start one here. meson has been adding -D_FILE_OFFSET_BITS=64 implicitly be default in some build configurations for a long time now. Since there is already precedent for doing that, it raises the question whether _TIME_BITS=64 should get the same treatment.

In short, setting _TIME_BITS=64 on certain 32-bit Linux platforms (x86, arm) will widen time-related types (e.g. time_t) and redirect function calls (e.g. time(), stat()) to variants that support 64-bit seconds on glibc 2.34 or later. It can only be use with -D_FILE_OFFSET_BITS=64.

• There is a problem with it right off the bat, setting _TIME_BITS=64 without _FILE_OFFSET_BITS=64 causes a compilation error, so projects using -U_FILE_OFFSET_BITS to undo meson will run into that.

• Autoconf already ships related options: AC_SYS_YEAR2038, AC_SYS_YEAR2038_RECOMMENDED.

Some links:

• https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/html_node/System-Services.html#index-AC_005fSYS_005fLARGEFILE-1
• https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fTIME_005fBITS
• https://sourceware.org/glibc/wiki/Y2038ProofnessDesign
• https://wiki.gentoo.org/wiki/Project:Toolchain/time64_migration
• https://musl.libc.org/time64.html

[dcbaker]

If we were building Meson today from scratch, I'd probably opt for setting _TIME_BITS=64 unconditionally as well, but today I doubt we can get away with that.

I'd be perfectly happy to have a b_time64 option that if that would simplify things.