From 67c20bbc7030d162132b7f7c7fbefbf95fc2bc76 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Thu, 1 Jul 2021 19:29:57 -0700 Subject: [PATCH 1/5] year2038: support glibc 2.34 _TIME_BITS=64 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit In glibc 2.34 on Linux kernels where time_t is traditionally 32-bit, defining _FILE_OFFSET_BITS=64 and _TIME_BITS=64 makes time_t 64-bit. Apps must define both macros. Gnulib applications that use either the largefile or the year2038 modules will want this behavior; largefile because it deals with the off_t and ino_t components of struct stat already, and so should also deal with time_t. * m4/largefile.m4: Override two macros even in Autoconf 2.70 and later. (_AC_SYS_LARGEFILE_MACRO_VALUE): #undef $1 before #defining it, in case some other Gnulib macro has #defined it. (AC_SYS_LARGEFILE): Use AS_IF and AS_CASE to propagate AC_REQUIREs. Invoke gl_YEAR2038_BODY if we need to set _FILE_OFFSET_BITS=64. * m4/year2038.m4 (gl_YEAR2038_TEST_INCLUDES): New macro. (gl_YEAR2038_BODY): New macro, with gl_YEAR2038’s old body; this macro is designed to be used directly instead of being AC_REQUIREd. It takes an argument specifying whether 64-bit is required. Set _TIME_BITS=64 if this makes a difference in time_t width when setting _FILE_OFFSET_BITS=64. Do not warn about 32-bit time_t more than once. * modules/largefile (Files): Add year2038.m4. (Depends-on): Require gl_YEAR2038_EARLY. Upstream-commit: dc09dc0888485698a8e74205b9df43159aef0f61 Signed-off-by: Kamil Dudka --- gl/m4/largefile.m4 | 28 +++++++++++---------- gl/m4/year2038.m4 | 63 ++++++++++++++++++++++++++++++++++++---------- 2 files changed, 65 insertions(+), 26 deletions(-) diff --git a/gl/m4/largefile.m4 b/gl/m4/largefile.m4 index cadb16d..172a4da 100644 --- a/gl/m4/largefile.m4 +++ b/gl/m4/largefile.m4 @@ -22,7 +22,8 @@ AC_DEFUN([gl_SET_LARGEFILE_SOURCE], esac ]) -# The following implementation works around a problem in autoconf <= 2.69; +# Work around a problem in Autoconf through at least 2.71 on glibc 2.34+ +# with _TIME_BITS. Also, work around a problem in autoconf <= 2.69: # AC_SYS_LARGEFILE does not configure for large inodes on Mac OS X 10.5, # or configures them incorrectly in some cases. m4_version_prereq([2.70], [], [ @@ -40,6 +41,7 @@ m4_define([_AC_SYS_LARGEFILE_TEST_INCLUDES], && LARGE_OFF_T % 2147483647 == 1) ? 1 : -1]];[]dnl ]) +])# m4_version_prereq 2.70 # _AC_SYS_LARGEFILE_MACRO_VALUE(C-MACRO, VALUE, @@ -54,7 +56,8 @@ m4_define([_AC_SYS_LARGEFILE_MACRO_VALUE], [AC_LANG_PROGRAM([$5], [$6])], [$3=no; break]) m4_ifval([$6], [AC_LINK_IFELSE], [AC_COMPILE_IFELSE])( - [AC_LANG_PROGRAM([#define $1 $2 + [AC_LANG_PROGRAM([#undef $1 +#define $1 $2 $5], [$6])], [$3=$2; break]) $3=unknown @@ -80,9 +83,8 @@ rm -rf conftest*[]dnl AC_DEFUN([AC_SYS_LARGEFILE], [AC_ARG_ENABLE(largefile, [ --disable-largefile omit support for large files]) -if test "$enable_largefile" != no; then - - AC_CACHE_CHECK([for special C compiler options needed for large files], +AS_IF([test "$enable_largefile" != no], + [AC_CACHE_CHECK([for special C compiler options needed for large files], ac_cv_sys_largefile_CC, [ac_cv_sys_largefile_CC=no if test "$GCC" != yes; then @@ -107,15 +109,15 @@ if test "$enable_largefile" != no; then ac_cv_sys_file_offset_bits, [Number of bits in a file offset, on hosts where this is settable.], [_AC_SYS_LARGEFILE_TEST_INCLUDES]) - if test $ac_cv_sys_file_offset_bits = unknown; then - _AC_SYS_LARGEFILE_MACRO_VALUE(_LARGE_FILES, 1, - ac_cv_sys_large_files, - [Define for large files, on AIX-style hosts.], - [_AC_SYS_LARGEFILE_TEST_INCLUDES]) - fi -fi + AS_CASE([$ac_cv_sys_file_offset_bits], + [unknown], + [_AC_SYS_LARGEFILE_MACRO_VALUE([_LARGE_FILES], [1], + [ac_cv_sys_large_files], + [Define for large files, on AIX-style hosts.], + [_AC_SYS_LARGEFILE_TEST_INCLUDES])], + [64], + [gl_YEAR2038_BODY([false])])]) ])# AC_SYS_LARGEFILE -])# m4_version_prereq 2.70 # Enable large files on systems where this is implemented by Gnulib, not by the # system headers. diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4 index 2534622..635ef12 100644 --- a/gl/m4/year2038.m4 +++ b/gl/m4/year2038.m4 @@ -1,4 +1,4 @@ -# year2038.m4 serial 3 +# year2038.m4 serial 4 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, @@ -18,13 +18,29 @@ AC_DEFUN([gl_YEAR2038_EARLY], esac ]) -AC_DEFUN([gl_YEAR2038], +# gl_YEAR2038_TEST_INCLUDES +# ------------------------- +AC_DEFUN([gl_YEAR2038_TEST_INCLUDES], +[[ + #include + /* Check that time_t can represent 2**63 - 1 correctly. + We can't simply define LARGE_TIME_T to be 9223372036854775807, + since some C++ compilers masquerading as C compilers + incorrectly reject 9223372036854775807. */ + #define LARGE_TIME_T (((time_t) 1 << 31 << 31) - 1 + ((time_t) 1 << 31 << 31)) + int verify_time_t_range[(LARGE_TIME_T % 2147483629 == 721 + && LARGE_TIME_T % 2147483647 == 1) + ? 1 : -1]; +]]) + +# gl_YEAR2038_BODY(REQUIRE-64-BIT) +---------------------------------- +AC_DEFUN([gl_YEAR2038_BODY], [ 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 and libc support to make it 64-bit. For glibc 2.34 and later on Linux, + dnl defining _TIME_BITS=64 and _FILE_OFFSET_BITS=64 is needed on x86 and ARM. 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 @@ -36,13 +52,28 @@ AC_DEFUN([gl_YEAR2038], 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]; - ]], - [[]])], + [AC_LANG_SOURCE([gl_YEAR2038_TEST_INCLUDES])], [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_CACHE_CHECK([for 64-bit time_t with _TIME_BITS=64], + [gl_cv_type_time_t_bits_macro], + [AC_COMPILE_IFELSE( + [AC_LANG_SOURCE([[#define _TIME_BITS 64 + #define _FILE_OFFSET_BITS 64 + ]gl_YEAR2038_TEST_INCLUDES])], + [gl_cv_type_time_t_bits_macro=yes], + [gl_cv_type_time_t_bits_macro=no]) + ]) + if test "$gl_cv_type_time_t_bits_macro" = yes; then + AC_DEFINE([_TIME_BITS], [64], + [Number of bits in a timestamp, on hosts where this is settable.]) + dnl AC_SYS_LARGFILE also defines this; it's OK if we do too. + AC_DEFINE([_FILE_OFFSET_BITS], [64], + [Number of bits in a file offset, on hosts where this is settable.]) + gl_cv_type_time_t_64=yes + fi + fi if test $gl_cv_type_time_t_64 = no; then AC_COMPILE_IFELSE( [AC_LANG_SOURCE( @@ -53,18 +84,24 @@ AC_DEFUN([gl_YEAR2038], #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 + [# If not cross-compiling and $1 says we should check, # 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 \ + 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'.]) - else + elif 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 ]) + +AC_DEFUN([gl_YEAR2038], +[ + gl_YEAR2038_BODY([test "${TIME_T_32_BIT_OK-no}" = no]) +]) -- 2.31.1 From 6df0907c00ee44cb36a7caa118d1a6492e0056e6 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Tue, 6 Jul 2021 15:21:44 -0700 Subject: [PATCH 2/5] 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 * 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. Upstream-commit: 7dd2562058aa4cc3a1a4714b6248193fd5444491 Signed-off-by: Kamil Dudka --- gl/m4/year2038.m4 | 23 ++++++++++++++--------- 1 file changed, 14 insertions(+), 9 deletions(-) diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4 index 635ef12..ad7f303 100644 --- a/gl/m4/year2038.m4 +++ b/gl/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.31.1 From 49816ad1b32b1f210841ac44cb64fa68da56806f Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 2 Aug 2021 09:30:50 -0700 Subject: [PATCH 3/5] year2038: port to unusual time_t platforms MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * m4/year2038.m4 (gl_YEAR2038_TEST_INCLUDES): Check that time_t can go to 2**32 - 1, not to 2**63 - 1, as the former is enough to be year 2038 safe. Unsigned 32-bit time_t (AmigaOS) and signed 40-bit time_t (Unisys ClearPath) have occurred in the wild, and even if Gnulib code is rarely or never ported to them there’s no need to exclude them merely because of year 2038 issues. (gl_YEAR2038_BODY): Adjust messages to match. Use 2**32 - 1, not 2**32, as the test timestamp, to allow unsigned 32-bit time_t. Upstream-commit: 784f55e5c59abde4eabf4e08169d1c50363280b4 Signed-off-by: Kamil Dudka --- gl/m4/year2038.m4 | 61 ++++++++++++++++++++++++++++------------------- 1 file changed, 36 insertions(+), 25 deletions(-) diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4 index ad7f303..7ae004e 100644 --- a/gl/m4/year2038.m4 +++ b/gl/m4/year2038.m4 @@ -1,11 +1,11 @@ -# year2038.m4 serial 5 +# year2038.m4 serial 6 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, dnl with or without modifications, as long as this notice is preserved. -dnl Attempt to ensure that 'time_t' is a 64-bit type -dnl and that the functions time(), stat(), etc. return 64-bit times. +dnl Attempt to ensure that 'time_t' can go past the year 2038 and that +dnl the functions 'time', 'stat', etc. work with post-2038 timestamps. AC_DEFUN([gl_YEAR2038_EARLY], [ @@ -23,18 +23,15 @@ AC_DEFUN([gl_YEAR2038_EARLY], AC_DEFUN([gl_YEAR2038_TEST_INCLUDES], [[ #include - /* Check that time_t can represent 2**63 - 1 correctly. - We can't simply define LARGE_TIME_T to be 9223372036854775807, - since some C++ compilers masquerading as C compilers - incorrectly reject 9223372036854775807. */ - #define LARGE_TIME_T (((time_t) 1 << 31 << 31) - 1 + ((time_t) 1 << 31 << 31)) - int verify_time_t_range[(LARGE_TIME_T % 2147483629 == 721 - && LARGE_TIME_T % 2147483647 == 1) + /* Check that time_t can represent 2**32 - 1 correctly. */ + #define LARGE_TIME_T (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)) + int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535 + && LARGE_TIME_T % 65537 == 0) ? 1 : -1]; ]]) -# gl_YEAR2038_BODY(REQUIRE-64-BIT) ----------------------------------- +# gl_YEAR2038_BODY(REQUIRE-YEAR2038-SAFE) +----------------------------------------- AC_DEFUN([gl_YEAR2038_BODY], [ AC_ARG_ENABLE([year2038], @@ -54,12 +51,12 @@ AC_DEFUN([gl_YEAR2038_BODY], 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_CACHE_CHECK([for time_t past the year 2038], [gl_cv_type_time_t_y2038], [AC_COMPILE_IFELSE( [AC_LANG_SOURCE([gl_YEAR2038_TEST_INCLUDES])], - [gl_cv_type_time_t_64=yes], [gl_cv_type_time_t_64=no]) + [gl_cv_type_time_t_y2038=yes], [gl_cv_type_time_t_y2038=no]) ]) - if test "$gl_cv_type_time_t_64" = no; then + if test "$gl_cv_type_time_t_y2038" = no; then AC_CACHE_CHECK([for 64-bit time_t with _TIME_BITS=64], [gl_cv_type_time_t_bits_macro], [AC_COMPILE_IFELSE( @@ -75,10 +72,10 @@ AC_DEFUN([gl_YEAR2038_BODY], dnl AC_SYS_LARGFILE also defines this; it's OK if we do too. AC_DEFINE([_FILE_OFFSET_BITS], [64], [Number of bits in a file offset, on hosts where this is settable.]) - gl_cv_type_time_t_64=yes + gl_cv_type_time_t_y2038=yes fi fi - if test $gl_cv_type_time_t_64 = no; then + if test $gl_cv_type_time_t_y2038 = no; then AC_COMPILE_IFELSE( [AC_LANG_SOURCE( [[#ifdef _USE_32BIT_TIME_T @@ -87,20 +84,34 @@ AC_DEFUN([gl_YEAR2038_BODY], error fail #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( + [The 'time_t' type stops working after January 2038. + Remove _USE_32BIT_TIME_T from the compiler flags.])], [# If not cross-compiling and $1 says we should check, - # and 'touch' works with a large timestamp, then evidently 64-bit time_t + # and 'touch' works with a large timestamp, then evidently wider time_t # is desired and supported, so fail and ask the builder to fix the # problem. Otherwise, just warn the builder. m4_ifval([$1], [if test $cross_compiling = no \ - && TZ=UTC0 touch -t 210602070628.16 conftest.time 2>/dev/null; then + && TZ=UTC0 touch -t 210602070628.15 conftest.time 2>/dev/null; then + case `TZ=UTC0 LC_ALL=C ls -l conftest.time 2>/dev/null` in + *'Feb 7 2106'* | *'Feb 7 17:10'*) + AC_MSG_FAILURE( + [The 'time_t' type stops working after January 2038, + and your system appears to support a wider 'time_t'. + Try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. + To build with a 32-bit time_t anyway (not recommended), + configure with '--disable-year2038'.]);; + esac 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 + if test "$gl_warned_about_y2038" != yes; then + AC_MSG_WARN( + [The 'time_t' type stops working after January 2038, + and this package needs a wider 'time_t' type + if there is any way to access timestamps after that. + Configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"' perhaps?]) + gl_warned_about_y2038=yes fi ]) fi]) @@ -108,5 +119,5 @@ AC_DEFUN([gl_YEAR2038_BODY], AC_DEFUN([gl_YEAR2038], [ - gl_YEAR2038_BODY([require-64-bit]) + gl_YEAR2038_BODY([require-year2038-safe]) ]) -- 2.31.1 From cd11a3e21d4aba6a8655a25bc0299cf4a72f58f5 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Mon, 2 Aug 2021 09:44:59 -0700 Subject: [PATCH 4/5] year2038: work even if time_t is narrower than int Upstream-commit: 7c6538cf0584a5ad3e2e46f64b1936eea4cddecc Signed-off-by: Kamil Dudka --- gl/m4/year2038.m4 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4 index 7ae004e..f53b03f 100644 --- a/gl/m4/year2038.m4 +++ b/gl/m4/year2038.m4 @@ -24,7 +24,8 @@ AC_DEFUN([gl_YEAR2038_TEST_INCLUDES], [[ #include /* Check that time_t can represent 2**32 - 1 correctly. */ - #define LARGE_TIME_T (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30)) + #define LARGE_TIME_T \\ + ((time_t) (((time_t) 1 << 30) - 1 + 3 * ((time_t) 1 << 30))) int verify_time_t_range[(LARGE_TIME_T / 65537 == 65535 && LARGE_TIME_T % 65537 == 0) ? 1 : -1]; -- 2.31.1 From 1e2e81f10204a4d176c8ec14bd95b9aa43d9012c Mon Sep 17 00:00:00 2001 From: Bruno Haible Date: Sat, 7 Aug 2021 16:03:22 +0200 Subject: [PATCH 5/5] year2038: Fix recommendation regarding -m64 flag. * m4/year2038.m4 (gl_YEAR2038_BODY): Recommend to put option --m64 in CC, not in CPPFLAGS and LDFLAGS. Upstream-commit: edb4fbdc959660ef753bdc684aaf14b555871a2a Signed-off-by: Kamil Dudka --- gl/m4/year2038.m4 | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/gl/m4/year2038.m4 b/gl/m4/year2038.m4 index f53b03f..da0f8d7 100644 --- a/gl/m4/year2038.m4 +++ b/gl/m4/year2038.m4 @@ -1,4 +1,4 @@ -# year2038.m4 serial 6 +# year2038.m4 serial 7 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, @@ -100,7 +100,7 @@ AC_DEFUN([gl_YEAR2038_BODY], AC_MSG_FAILURE( [The 'time_t' type stops working after January 2038, and your system appears to support a wider 'time_t'. - Try configuring with 'CPPFLAGS="-m64" LDFLAGS="-m64"'. + Try configuring with 'CC="${CC} -m64"'. To build with a 32-bit time_t anyway (not recommended), configure with '--disable-year2038'.]);; esac @@ -111,7 +111,7 @@ AC_DEFUN([gl_YEAR2038_BODY], [The 'time_t' type stops working after January 2038, and this package needs a wider 'time_t' type if there is any way to access timestamps after that. - Configure with 'CPPFLAGS="-m64" LDFLAGS="-m64"' perhaps?]) + Configure with 'CC="${CC} -m64"' perhaps?]) gl_warned_about_y2038=yes fi ]) -- 2.31.1