+2017-11-06 Paul Eggert <eggert@cs.ucla.edu>
+
+ 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.
+
2017-11-05 Paul Eggert <eggert@cs.ucla.edu>
havelib: fix typo in previous change
-# 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,
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,
[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
#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
])