largefile: sync from Autoconf master

* modules/largefile-required, modules/year2038-required: New modules.
* MODULES.html.sh, doc/largefile.texi, doc/posix-headers/time.texi:
* doc/year2038.texi: Document this.
* m4/largefile.m4: Sync from Autoconf master.
Conditionalize the workaround on AC_SYS_LARGEFILE_REQUIRED rather
than on AC_SYS_YEAR2038 so that we replace older but still
unreleased Autoconf.
(AC_SYS_LARGEFILE_REQUIRED, AC_SYS_YEAR2038_REQUIRED): New macros.

1 files changed, 6 insertions, 2 deletions

diff --git a/doc/posix-headers/time.texi b/doc/posix-headers/time.texi
index 5ecebbfdda..a506ec640c 100644
--- a/doc/posix-headers/time.texi
+++ b/doc/posix-headers/time.texi
@@ -18,14 +18,16 @@ expressions:
 NetBSD 5.0.
 @end itemize
 
-Portability problems fixed by the Gnulib module @code{year2038}:
+Portability problems fixed by the Gnulib modules
+@code{year2038-required} and @code{year-2038}:
 @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.
+glibc 2.34+ atop 32-bit x86 or ARM Linux.
+@xref{Avoiding the year 2038 problem}.
 @end itemize
 
 Portability problems not fixed by Gnulib:
@@ -39,6 +41,8 @@ the functions silently return the low-order 32 bits of the correct
 timestamp.  These platforms will be obsolete when 32-bit @code{time_t}
 rolls around, which will occur in 2038 for the typical case when
 @code{time_t} is signed.
+@xref{Avoiding the year 2038 problem}.
+
 @item
 On some platforms the @code{tv_nsec} member of @code{struct timespec}
 is not of type @code{long}, but is of type @code{long long} instead: