On 7/5/21 6:34 PM, Bruno Haible wrote:
What are these appropriate flags?
It was "./configure TIME_T_32_BIT_OK=yes". Though this wasn't documented
well and perhaps needed other options, and it's different in style from
how largefile worked.
I'd like to understand
- whether these flags are simple or complicated,
They should be simple.
- whether we really do need a module dependency 'largefile' -> 'year2038',
- how to best document these things.
It shouldn't be a module dependency, since year2038 means "I must have
64-bit time_t or I won't build" whereas largefile merely means "I want
the widest off_t/dev_t/ino_t/time_t available". That being said,
largefile can use some of the year2038 macros.
we need an
AC_ARG_ENABLE([year2038], ...)
like we already have an
AC_ARG_ENABLE([largefile], ...)
Yes, something like that would be better than the TIME_T_32_BIT_OK flag.
I installed the attached patches into Gnulib to implement the above
suggestions. The first one is just a doc fix; the second one does the
real work.
From 8d8007df5e302f7f74faefc0f87983adbbc1c8c8 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
Date: Tue, 6 Jul 2021 15:08:05 -0700
Subject: [PATCH 1/2] 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
by the time module.
---
ChangeLog | 7 +++++++
doc/posix-headers/time.texi | 16 ++++++++++------
2 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index b00dfd1fd..3cd55e5ba 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2021-07-06 Paul Eggert <egg...@cs.ucla.edu>
+
+ 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
+ by the time module.
+
2021-07-01 Paul Eggert <egg...@cs.ucla.edu>
year2038: support glibc 2.34 _TIME_BITS=64
diff --git a/doc/posix-headers/time.texi b/doc/posix-headers/time.texi
index b9be347c7..3d8164645 100644
--- a/doc/posix-headers/time.texi
+++ b/doc/posix-headers/time.texi
@@ -8,12 +8,6 @@ Gnulib module: time
Portability problems fixed by Gnulib:
@itemize
@item
-On some platforms where @code{time_t} defaults to 32-bit but can be
-changed to 64-bit, functions like @code{stat} can fail with
-@code{errno == EOVERFLOW} when a 32-bit timestamp is out of range,
-such as with a file timestamp in the far future or past:
-glibc 2.34.
-@item
@samp{struct timespec} is not defined on some platforms.
@item
The macro @code{TIME_UTC} is not defined on many platforms:
@@ -24,6 +18,16 @@ expressions:
NetBSD 5.0.
@end itemize
+Portability problems fixed by the Gnulib module @code{year2038}:
+@itemize
+@item
+On some platforms where @code{time_t} defaults to 32-bit but can be
+changed to 64-bit, functions like @code{stat} can fail with
+@code{errno == EOVERFLOW} when a 32-bit timestamp is out of range,
+such as with a file timestamp in the far future or past:
+glibc 2.34.
+@end itemize
+
Portability problems not fixed by Gnulib:
@itemize
@item
--
2.30.2
From 12169c73bc0008553e6786cd8ef39ccf28cc1519 Mon Sep 17 00:00:00 2001
From: Paul Eggert <egg...@cs.ucla.edu>
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 <egg...@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
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
