Re: autoreconf as used by Debian

Santiago Vila wrote:
> > Hello. I tested the new snapshot and found the following issues:
> > 
> > * It still does not allow to run autoreconf.
> > 
> > configure.ac:36: warning: The macro 'AC_HELP_STRING' is obsolete.
> > configure.ac:36: You should run autoupdate.
> > ./lib/autoconf/general.m4:204: AC_HELP_STRING is expanded from...
> > m4/threadlib.m4:36: gl_THREADLIB_EARLY_BODY is expanded from...
> > m4/threadlib.m4:29: gl_THREADLIB_EARLY is expanded from...
> > m4/gnulib-comp.m4:34: M4_EARLY is expanded from...
> > configure.ac:36: the top level
> ...

The complete log is in
  <https://lists.gnu.org/archive/html/bug-m4/2025-04/msg00064.html>.
It shows that 'autoreconf' has installed a file m4/threadlib.m4
that
  - in line 36 invokes AC_HELP_STRING (which gnulib/m4/threadlib.m4
    does not do any more since 2020-09-27),
  - does not contain a definition of gl_PTHREADLIB (which gnulib/m4/threadlib.m4
    defines since 2019-12-02).

There are only two possible sources for such an old threadlib.m4 file:
  - An old copy of Gnulib,
  - The macros installed by GNU gettext version 0.24 or older (fixed
    for the next release 0.24.1 [1]).

> This seems to be a weakness in the bootstrap project; I'm not sure I
> know how to fix it, but hope Gary can take a look.

No, that is not a weakness in Gary's 'bootstrap' project. It is due
to the use of 'autoreconf' done on the Debian side.

1) 'autoreconf' is generally not supported by GNU packages. ([2] does
   not mention that running 'autoreconf' should be supported.)
   It may work or it may not work.

2) Eric's m4 snapshot has the option "-I m4" in the ACLOCAL_AMFLAGS
   of the top-level Makefile.am. This is generally sufficient to ensure
   that 'autoreconf' can run successfully (even with older releases
   of Autoconf, that don't implement the AC_CONFIG_MACRO_DIRS macro).

3) Debian is apparently having *.m4 files in the
   $PREFIX/share/aclocal/ directory that are from 2019 or older
   *and* telling autoreconf to install these old files into the local
   m4/ directory. (Inferred from the logs, above.)
   - If these files come from Gnulib directly, it would be against
     Gnulib philosophy, see [3][4].
     The oldest stable branch of Gnulib that is still supported is
     'stable-202407'. And even that is not guaranteed to work with
     Eric's m4 snapshot: When a package maintainer has made a release
     with a specific Gnulib version, you are not supposed to use an
     older Gnulib version. (A newer Gnulib version should work, assuming
     you pay attention to the backwards-incompatible changes mentioned
     in the gnulib/NEWS file.)
   - If they come from Gettext, please use patch [1].

4) Santiago Vila has encountered a similar problem where Debian's
   dh_* programs bring in unrequested versions of *.m4 files. I told
   him on 2025-02-26:
   "My conclusion is that what you are seeing is a bug in the dh_* programs.
    One of them apparently installed gettext.m4 from version 0.22 or 0.23
    instead of from 0.18, as required per the line in configure.ac."

In summary: Debian should run autoreconf on a machine that contains
in $PREFIX/share/aclocal/ *only*
  - the *.m4 files from Autoconf,
  - the *.m4 files from Automake,
  - maybe a reasonable version of pkg.m4 (0.29.1, not 0.29.2).
That directory should *not* contain
  - the *.m4 files from Libtool (because libtool.sh and libtool.m4 need
    to come from the same Libtool version),
  - the *.m4 files from Gettext (because po/Makefile.in.in and po.m4 need
    to come from the same Gettext version),
  - any *.m4 files from Gnulib.

THEN AND ONLY THEN you have a chance of doing a reasonable and successful
'autoreconf'.

Bruno

[1] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=02c475e2f3a64a9cc4e1caa9e712e5e643178579
[2] https://www.gnu.org/prep/standards/standards.html
[3] https://www.gnu.org/software/gnulib/manual/html_node/Keeping-Up_002dto_002ddate.html
[4] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html