Re: remaining tasks before Autoconf release

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 <[email protected]>
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