From ccc0d640c4d829504568330f9674408af5092ffc Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 13 May 2023 09:56:33 -0700
Subject: [PATCH 23/29] Improve AC_SYS_YEAR2038_RECOMMENDED diagnostic

* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_RECOMMENDED):
Do not recommend gcc -m64, as that likely will not work.
Problem reported by Bruno Haible in:
https://lists.gnu.org/r/bug-gnulib/2023-05/msg00060.html
Instead, mention that 32-bit time_t is not recommended
for this package, before telling the builder how
to configure with 32-bit time_t anyway.

Upstream-Status: Backport
Signed-off-by: Khem Raj <raj.khem@gmail.com>
---
 lib/autoconf/specific.m4 | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 88e0479e8..91f20bf0d 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -228,8 +228,9 @@ AC_DEFUN([AC_SYS_YEAR2038_RECOMMENDED],
 AS_IF([test "$enable_year2038,$ac_have_year2038" = yes,no],
    [AC_MSG_FAILURE(m4_text_wrap(
       [could not enable timestamps after mid-January 2038.
-       Did you mean to build a 64-bit binary? (E.g., 'CC="${CC} -m64"'.)
-       To proceed with 32-bit time_t, configure with '--disable-year2038'.],
+       This package recommends support for these later timestamps.
+       However, to proceed with signed 32-bit time_t even though it
+       will fail then, configure with '--disable-year2038'.],
       [], [], [55]))])])
 
 # _AC_SYS_LARGEFILE_TEST_CODE
-- 
2.41.0

