From 12169c73bc0008553e6786cd8ef39ccf28cc1519 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 6 Jul 2021 15:21:44 -0700 Subject: [PATCH 2/2] year2038: Add --disable-year2038 option MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 | 10 ++++++++++ doc/year2038.texi | 19 +++++++++++++++++-- m4/largefile.m4 | 2 +- m4/year2038.m4 | 23 ++++++++++++++--------- 4 files changed, 42 insertions(+), 12 deletions(-) diff --git a/ChangeLog b/ChangeLog index 3cd55e5ba..2eaf00b59 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,15 @@ 2021-07-06 Paul Eggert + 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 diff --git a/doc/year2038.texi b/doc/year2038.texi index de85bc6d2..213fda235 100644 --- a/doc/year2038.texi +++ b/doc/year2038.texi @@ -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. diff --git a/m4/largefile.m4 b/m4/largefile.m4 index 172a4da96..fbde5e664 100644 --- a/m4/largefile.m4 +++ b/m4/largefile.m4 @@ -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 diff --git a/m4/year2038.m4 b/m4/year2038.m4 index 635ef124f..ad7f30358 100644 --- a/m4/year2038.m4 +++ b/m4/year2038.m4 @@ -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]) ]) -- 2.30.2