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
