On 2023-05-12 05:32, Bruno Haible wrote:
there are two AC_MSG_FAILURE invocations. Removing this
line from the invocation in AC_SYS_YEAR2038_RECOMMENDED does not remove it
from the invocation in AC_SYS_YEAR2038.
Oh, thanks for explaining that. I installed the attached patch to
address the problem you mentioned. It doesn't quite follow your
suggestion, as it also adds some wording mentioning that year-2038
support is recommended for the package, before notifying the builder how
to go ahead and use 32-bit time_t anyway.From ccc0d640c4d829504568330f9674408af5092ffc Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@xxxxxxxxxxx>
Date: Sat, 13 May 2023 09:56:33 -0700
Subject: [PATCH] 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.
---
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 88e0479e..91f20bf0 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.39.2
