On 2023-03-02 01:04, Daniel P. Berrangé wrote:
IMHO if distros really want to deal with this, they need to be able to force _TIME_BITS=64 globally / unconditionally, and do a mass rebuild.
As things stand this is probably the best way to go. Although some pain is inevitable, this approach appears to be the least painful.
Mainstream developers long ago migrated to 64-bit time_t, and fewer and fewer of them have the time to worry about the shrinking subset of the embedded system world where legacy 32-bit time_t is still OK (at least for the next several months). It's incumbent on system builders who still cater to legacy 32-bit time_t (for now) to figure out how to wrangle their systems into the 64-bit time_t world; they can't really expect Glibc, Gnulib, Autoconf, GnuTLS, etc. to make the job much easier than it already is.
So while there is a chance of inconsistent usage [with off_t], and thus ABI incompatibility, in practice this is a non-issue since everything of consequence has long ago opted in to _FILE_OFFSET_BITS=64.
Fifteen years from now we'll be saying the same thing about _TIME_BITS. There will be some pain in the meantime, just as there was with the _FILE_OFFSET_BITS transition, something I lived through and was not too happy about either.
