From 284f1da866b9897d267e2fe8cf7292f32eae0964 Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 11 Nov 2017 15:14:26 +0100 Subject: [PATCH] year2038: Tweak last patch. * m4/year2038.m4 (gl_YEAR2038): Correct indentation. --- ChangeLog | 5 +++ m4/year2038.m4 | 94 +++++++++++++++++++++++++------------------------- 2 files changed, 52 insertions(+), 47 deletions(-) diff --git a/ChangeLog b/ChangeLog index cad5ed70da..7eeb1c4ff6 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2017-11-11 Bruno Haible + + year2038: Tweak last patch. + * m4/year2038.m4 (gl_YEAR2038): Correct indentation. + 2017-11-06 Paul Eggert year2038: be more insistent about 64-bit time_t diff --git a/m4/year2038.m4 b/m4/year2038.m4 index ccc905c919..9cd579e6b5 100644 --- a/m4/year2038.m4 +++ b/m4/year2038.m4 @@ -20,51 +20,51 @@ AC_DEFUN([gl_YEAR2038_EARLY], AC_DEFUN([gl_YEAR2038], [ - 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 . - 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, - dnl - __time64_t on 64-bit mingw and on MSVC (since MSVC 8). - dnl But when compiling with -D__MINGW_USE_VC2005_COMPAT, time_t is an - dnl alias of __time64_t. - dnl And when compiling with -D_USE_32BIT_TIME_T, time_t is an alias of - dnl __time32_t. - AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64], - [AC_COMPILE_IFELSE( - [AC_LANG_PROGRAM( - [[#include - int verify_time_t_size[sizeof (time_t) >= 8 ? 1 : -1]; - ]], - [[]])], - [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no]) - ]) - if test $gl_cv_type_time_t_64 = no; then - AC_COMPILE_IFELSE( - [AC_LANG_SOURCE( - [[#ifdef _USE_32BIT_TIME_T - int ok; - #else - error fail - #endif - ]])], - [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])], - [# 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 . + 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, + dnl - __time64_t on 64-bit mingw and on MSVC (since MSVC 8). + dnl But when compiling with -D__MINGW_USE_VC2005_COMPAT, time_t is an + dnl alias of __time64_t. + dnl And when compiling with -D_USE_32BIT_TIME_T, time_t is an alias of + dnl __time32_t. + AC_CACHE_CHECK([for 64-bit time_t], [gl_cv_type_time_t_64], + [AC_COMPILE_IFELSE( + [AC_LANG_PROGRAM( + [[#include + int verify_time_t_size[sizeof (time_t) >= 8 ? 1 : -1]; + ]], + [[]])], + [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no]) + ]) + if test $gl_cv_type_time_t_64 = no; then + AC_COMPILE_IFELSE( + [AC_LANG_SOURCE( + [[#ifdef _USE_32BIT_TIME_T + int ok; + #else + error fail + #endif + ]])], + [AC_MSG_FAILURE([This package requires a 64-bit 'time_t' type. Remove _USE_32BIT_TIME_T from the compiler flags.])], + [# 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 ]) -- 2.39.5