year2038: be more insistent about 64-bit time_t

Applications requiring access to arbitrary files should not be
built with 32-bit time_t on hosts that have 64-bit timestamps,
as this can lead to real trouble at runtime.
* m4/year2038.m4 (gl_YEAR2038): Do not require AC_CANONICAL_HOST.
Check on all systems, not just MinGW.  Use a heuristic involving
TIME_T_32_BIT_OK, cross_compiling, and the touch command to
output a failure or just a warning, to make it more likely that
builders will select 64-bit time_t.

1 files changed, 20 insertions, 16 deletions

diff --git a/m4/year2038.m4 b/m4/year2038.m4
index b9adc99bdb..ccc905c919 100644
--- a/m4/year2038.m4
+++ b/m4/year2038.m4
@@ -1,4 +1,4 @@
-# year2038.m4 serial 2
+# year2038.m4 serial 3
 dnl Copyright (C) 2017 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -20,9 +20,12 @@ AC_DEFUN([gl_YEAR2038_EARLY],
 
 AC_DEFUN([gl_YEAR2038],
 [
-  AC_REQUIRE([AC_CANONICAL_HOST])
-  case "$host_os" in
-    mingw*)
+      dnl On many systems, time_t is already a 64-bit type.
+      dnl On those systems where time_t is still 32-bit, it requires kernel
+      dnl and libc support to make it 64-bit. For glibc on Linux/x86, this
+      dnl is work in progress; see
+      dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
+      dnl
       dnl On native Windows, the system include files define types __time32_t
       dnl and __time64_t. By default, time_t is an alias of
       dnl   - __time32_t on 32-bit mingw,
@@ -41,8 +44,6 @@ AC_DEFUN([gl_YEAR2038],
            [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no])
         ])
       if test $gl_cv_type_time_t_64 = no; then
-        dnl Just bail out if 'time_t' is not 64-bit, and let the user fix the
-        dnl problem.
         AC_COMPILE_IFELSE(
           [AC_LANG_SOURCE(
              [[#ifdef _USE_32BIT_TIME_T
@@ -52,15 +53,18 @@ AC_DEFUN([gl_YEAR2038],
                #endif
              ]])],
           [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])],
-          [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Your system include files surely provide a way to make 'time_t' an alias of '__time64_t'.])])
+          [# If TIME_T_32_BIT_OK is "no" (the default) and not cross-compiling
+           # and 'touch' works with a large timestamp, then evidently
+           # 64-bit time_t is desired and supported, so fail and ask
+           # the builder to fix the problem.  Otherwise, just warn the
+           # builder.
+           if test "${TIME_T_32_BIT_OK-no}" = no &&
+              test $cross_compiling = no &&
+              TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then
+             rm -f conftest.time
+             AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type, which your system appears to support. You might try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. To build with a 32-bit time_t anyway (not recommended), configure with 'TIME_T_32_BIT_OK=yes'.])
+           else
+             AC_MSG_WARN([This package requires a 64-bit 'time_t' type if there is any way to access timestamps outside the year range 1901-2038 on your platform. Perhaps you should configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"'?])
+           fi])
       fi
-      ;;
-    *)
-      dnl On many systems, time_t is already a 64-bit type.
-      dnl On those systems where time_t is still 32-bit, it requires kernel
-      dnl and libc support to make it 64-bit. For glibc on Linux/x86, this
-      dnl is work in progress; see
-      dnl <https://sourceware.org/glibc/wiki/Y2038ProofnessDesign>.
-      ;;
-  esac
 ])