Always define __USE_TIME_BITS64 when 64 bit time_t is used

It was raised on libc-help [1] that some Linux kernel interfaces expect
the libc to define __USE_TIME_BITS64 to indicate the time_t size for the
kABI.  Different than defined by the initial y2038 design document [2],
the __USE_TIME_BITS64 is only defined for ABIs that support more than
one time_t size (by defining the _TIME_BITS for each module).

The 64 bit time_t redirects are now enabled using a different internal
define (__USE_TIME64_REDIRECTS). There is no expected change in semantic
or code generation.

Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and
arm-linux-gnueabi

[1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html
[2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Reviewed-by: DJ Delorie <dj@redhat.com>
(cherry picked from commit a4ed0471d71739928a0d0fa3258b3ff3b158e9b9)

1 files changed, 6 insertions, 0 deletions

diff --git a/manual/creature.texi b/manual/creature.texi
index fa5dd9d6ad..8d19e9dd73 100644
--- a/manual/creature.texi
+++ b/manual/creature.texi
@@ -192,6 +192,12 @@ Linux kernel version on which the system is running. For Linux kernel
 version above @b{5.1} syscalls supporting 64-bit time are used. Otherwise,
 a fallback code is used with legacy (i.e. 32-bit) syscalls.
 
+On such platforms, @theglibc{} will also define @code{__USE_TIME64_REDIRECTS}
+to indicate whether the declarations are expanded to different ones
+(either by redefiniding the symbol name or using symbol aliais).
+For instance, if the symbol @code{clock_gettime} expands to
+@code{__glock_gettime64}.
+
 @item
 If @code{_TIME_BITS} is defined to be 32, @code{time_t} is defined to
 be a 32-bit integer where that is supported.  This is not recommended,