Hi Paul,
> > I see two issues:
> >
> > 1) For AC_SYS_YEAR2038 and AC_SYS_YEAR2038_RECOMMENDED, when run on a 32-bit
> > platform (x86) with glibc < 2.34, there is no
> > checking for <$CC> option for timestamps after 2038...
> > line in the output. It _looks_like_ the macro was not invoked or did no
> > checks. This is quite confusing for a developer who wants to understand what
> > happened.
> > Suggestion: Print
> > checking for gcc option for timestamps after 2038... support not detected
>
> That's odd, since I just tried it and it worked for me. That is, I ran
>
> ./gnulib-tool --create-testdir --dir foo -h year2038-recommended
When I say "I test a testdir without gnulib and it has two issues"
and you say "I test a testdir with gnulib and it works", this is no
contradiction. These are simply different test cases.
I was testing without gnulib first, because
- if there are issues without gnulib, it is easier to investigate
than with gnulib,
- if there are issues with gnulib but not without gnulib, the
investigation should focus on gnulib/m4/largefile.m4.
The testdirs without gnulib, that I attached to
https://lists.gnu.org/archive/html/autoconf/2023-04/msg00030.html,
are still the current ones. (Regenerating them with the newest autoconf
only changes s/2.72c.20-a347/2.72c.20-9c018/ .)
But I made a mistake during this testing: My testing script on that
particular machine (glibc 2.27/x86) was always adding --disable-year2038;
this explains the absence of output. Without this option, the results are:
==== hello-lf ====
glibc x86 2.27
checking for gcc option to enable large file support... -D_FILE_OFFSET_BITS=64
==== hello-2038 ====
glibc x86 2.27
checking for gcc option to enable large file support... -D_FILE_OFFSET_BITS=64
checking for gcc option for timestamps after 2038... support not detected
==== hello-2038rc ====
glibc x86 2.27
checking for gcc option to enable large file support... -D_FILE_OFFSET_BITS=64
checking for gcc option for timestamps after 2038... support not detected
configure: error: in '/home/bruno/hello-2038rc/build':
configure: error: could not enable timestamps after mid-January 2038.
Did you mean to build a 64-bit binary? (E.g.,
'CC="gcc -m64"'.) To proceed with 32-bit time_t,
configure with '--disable-year2038'.
See 'config.log' for more details
The two issues I reported earlier are moot. But there is one other issue:
3) The hint
Did you mean to build a 64-bit binary? (E.g.,
'CC="gcc -m64"'.)
should not occur on a 32-bit OS. It should only occur on bi-arch systems
(64-bit OS, 32-bit $CC).
On my test machine, Ubuntu 18.04 32-bit, "gcc -m64" does not work:
$ gcc -m64 hello.c
In file included from hello.c:1:0:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
On your test machine, gcc45.fsffrance.org, "gcc -m64" works but produces
executables that don't work:
$ uname -a
Linux gcc45 3.16.0-11-686-pae #1 SMP Debian 3.16.84-1 (2020-06-09) i686 GNU/Linux
$ gcc -m64 hello.c
$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=71f55073fdd349a5de86d90ace175f4ee3a2f2c6, not stripped
$ ./a.out
-bash: ./a.out: cannot execute binary file: Exec format error
In both cases, this suggestion to build a 64-bit binary is pointless and
thus should be omitted.
Only on a bi-arch system, such as gcc13.fsffrance.org, with CC="gcc -m32",
the configure output is
checking for gcc -m32 option to enable large file support... -D_FILE_OFFSET_BITS=64
checking for gcc -m32 option for timestamps after 2038... support not detected
configure: error: in '/home/haible/hello-2038rc':
configure: error: this system appears to support timestamps after
mid-January 2038, but no mechanism for enabling wide
'time_t' was detected. Did you mean to build a 64-bit
binary? (E.g., 'CC="gcc -m32 -m64"'.) To proceed with
32-bit time_t, configure with '--disable-year2038'.
See 'config.log' for more details
and here the suggestion to build a 64-bit binary is justified.
In other words, what I am suggesting is the attached patch.
Bruno
>From 79c5c4fdcc0a4f7367e71ceb212052e3382141bc Mon Sep 17 00:00:00 2001
From: Bruno Haible <bruno@xxxxxxxxx>
Date: Sat, 6 May 2023 12:02:56 +0200
Subject: [PATCH] AC_SYS_YEAR2038_RECOMMENDED: Improve configure output upon
failure.
* lib/autoconf/specific.m4 (AC_SYS_YEAR2038_RECOMMENDED): Don't suggest to build
a 64-bit binary here. On bi-arch systems, where 64-bit binaries are possible,
AC_SYS_YEAR2038 already emitted this suggestion when failing.
---
lib/autoconf/specific.m4 | 1 -
1 file changed, 1 deletion(-)
diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 88e0479e..debff0c7 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -228,7 +228,6 @@ 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'.],
[], [], [55]))])])
--
2.34.1
