year2038: Add --disable-year2038 option
authorPaul Eggert <eggert@cs.ucla.edu>
Tue, 6 Jul 2021 22:21:44 +0000 (15:21 -0700)
committerPaul Eggert <eggert@cs.ucla.edu>
Tue, 6 Jul 2021 22:22:27 +0000 (15:22 -0700)
Also, document this stuff better.  Suggested by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2021-07/msg00011.html
* doc/year2038.texi: Document --disable-year2038.
* m4/year2038.m4 (gl_YEAR2038_BODY): Support ‘./configure
--disable-year2038’ to disable 64-bit time_t when that is not the
default.  Arg is now either empty or nonempty (not a shell
command) and is evaluated at m4 expansion time instead of at
runtime; all callers changed.

ChangeLog
doc/year2038.texi
m4/largefile.m4
m4/year2038.m4

index 3cd55e5ba7cb69172ea2b50d8fbcb7b7266de7d0..2eaf00b59174403b481a3a9776ee7b468a0d042d 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,15 @@
 2021-07-06  Paul Eggert  <eggert@cs.ucla.edu>
 
+       year2038: Add --disable-year2038 option
+       Also, document this stuff better.  Suggested by Bruno Haible in:
+       https://lists.gnu.org/r/bug-gnulib/2021-07/msg00011.html
+       * doc/year2038.texi: Document --disable-year2038.
+       * m4/year2038.m4 (gl_YEAR2038_BODY): Support ‘./configure
+       --disable-year2038’ to disable 64-bit time_t when that is not the
+       default.  Arg is now either empty or nonempty (not a shell
+       command) and is evaluated at m4 expansion time instead of at
+       runtime; all callers changed.
+
        doc: clarify which module fixes 32-bit time_t
        * doc/posix-headers/time.texi: Make it clear that the 32-bit
        time_t problem is addressed by the year2038 module, not
index de85bc6d281f0a93b8d9a5fd76585b3da47deaa6..213fda235f27c08ba827f392389fbfcb23a8aba4 100644 (file)
@@ -6,5 +6,20 @@ that will likely occur in the year 2038, for programs that use a 32-bit
 @samp{time_t} type.  See @url{https://en.wikipedia.org/wiki/Year_2038_problem}
 for details.
 
-The gnulib module @samp{year2038} attempts to avoid this problem, by
-ensuring that @code{time_t} is a 64-bit type.
+The Gnulib module @samp{year2038} attempts to avoid this problem, by
+ensuring that @code{time_t} is a 64-bit type and by causing
+@code{configure} to fail otherwise.
+
+The Gnulib module @samp{largefile} also attempts to avoid this problem
+when possible, because @samp{largefile} enables the widest
+file-related types supported by the system and @code{time_t} is one of
+those types.  However, @code{largefile} does not cause
+@code{configure} to fail when the year 2038 problem is not avoidable.
+
+The Gnulib @samp{largefile} and @samp{year2038} modules are
+recommended for any package that might be used after the year 2038 on
+32-bit platforms.  However, if you build such a package you can
+disable its use of 64-bit @code{time_t} by giving the
+@code{--disable-year2038} option to @code{configure}.  This may be
+useful if the package links to other libraries whose user-facing ABIs
+still require @code{time_t} to be 32-bit on your platform.
index 172a4da96a234bed1cb1fe512dcd92555f7c627c..fbde5e66471e5df3f4f090593d0607906b2664ef 100644 (file)
@@ -116,7 +116,7 @@ AS_IF([test "$enable_largefile" != no],
          [Define for large files, on AIX-style hosts.],
          [_AC_SYS_LARGEFILE_TEST_INCLUDES])],
     [64],
-      [gl_YEAR2038_BODY([false])])])
+      [gl_YEAR2038_BODY([])])])
 ])# AC_SYS_LARGEFILE
 
 # Enable large files on systems where this is implemented by Gnulib, not by the
index 635ef124fc01df8b8574859fe3389ba0eadbc6c2..ad7f3035815d3be5c11f57cc6b06ed2db55979e2 100644 (file)
@@ -1,4 +1,4 @@
-# year2038.m4 serial 4
+# year2038.m4 serial 5
 dnl Copyright (C) 2017-2021 Free Software Foundation, Inc.
 dnl This file is free software; the Free Software Foundation
 dnl gives unlimited permission to copy and/or distribute it,
@@ -37,6 +37,10 @@ AC_DEFUN([gl_YEAR2038_TEST_INCLUDES],
 ----------------------------------
 AC_DEFUN([gl_YEAR2038_BODY],
 [
+ AC_ARG_ENABLE([year2038],
+   [  --disable-year2038      omit support for timestamps past the year 2038])
+ AS_IF([test "$enable_year2038" != no],
+ [
   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 2.34 and later on Linux,
@@ -88,20 +92,21 @@ AC_DEFUN([gl_YEAR2038_BODY],
        # 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 $1 \
-          && 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'.])
-       elif test "$gl_warned_about_64_bit_time_t" != yes; then
+       m4_ifval([$1],
+         [if 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 '--disable-year2038'.])
+          fi])
+       if test "$gl_warned_about_64_bit_time_t" != yes; then
          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"'?])
          gl_warned_about_64_bit_time_t=yes
        fi
       ])
-  fi
+  fi])
 ])
 
 AC_DEFUN([gl_YEAR2038],
 [
-  gl_YEAR2038_BODY([test "${TIME_T_32_BIT_OK-no}" = no])
+  gl_YEAR2038_BODY([require-64-bit])
 ])