Hi Andy, Thanks for CCing me. You could equally well have CCed bug-gnulib; that works too.
> To recap, gnulib provides compile-time shims for "foreign" or > out-of-date target systems that allows Guile to program to a single > POSIX + GNU API and not worry too much about what the system actually > offers. Gnulib also has other functionality than portability. There is also - build / maintenance infrastructure (which Guile makes use of), - other functionality [1]. > However I was unable to update gnulib before the most > recent release. The reason is essentially the problem described in this > issue: > > https://sourceware.org/bugzilla/show_bug.cgi?id=30051 > > To wit, running "autoreconf -vif" invokes the "autopoint" tool supplied > by installed gettext, which copies over .m4 files from installed > gettext, but these files are older than the ones that are already > "vendored" in-tree by gnulib. Other parts of gnulib depend on the newer > gnulib-supplied macros which were stompled over; autoconf thus fails to > run. I can reproduce a problem by 0. using a git checkout of guile ('main' branch, not 'master' branch), 1. using a GNU gettext version 0.22.5, 0.21, 0.20.2, or 0.19.8.1, 2. removing the gnulib-local/m4/clock_time.m4.diff file, which no longer applies, 3. running $ $GNULIB_SRCDIR/gnulib-tool --update 4. running $ ./autogen.sh (which is what the HACKING file recommends). It fails with configure:12833: error: possibly undefined macro: gl_PTHREADLIB If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure:12943: error: possibly undefined macro: gl_WEAK_SYMBOLS configure:27584: error: possibly undefined macro: gl_TYPE_WINT_T_PREREQ autoreconf: error: /usr/bin/autoconf failed with exit status: 1 Following your analysis, I locally apply the workaround from the Gnulib documentation section "3.11 Caveat: gettextize and autopoint users", redo steps 3 and 4, and the './configure' succeeds, and 'make' succeeds up to the point where it encounters a compilation error: CC libguile_3.0_la-jit.lo jit.c:373:30: error: macro "unreachable" passed 1 arguments, but takes just 0 373 | unreachable (scm_jit_state *j) | ^ Explanation: 'unreachable' is, per ISO C 23 § 7.21.1, a macro that takes 0 arguments. The newer Gnulib makes it available even if the compiler does not yet make it available. Proposed patch attached. > 1. Some projects (e.g. poke) seem to import the whole of gnulib as a > git submodule, and then run "gnulib-tool --update" from that > submodule as part of their bootstrap. In this way the stompled > files are restored. However I do not want git submodules in Guile; > they add additional steps for every time you change to a different > HEAD, and I know from experience that I can't rely on myself to > perform them all, much less any user with a bug report. Do not > want. The way Guile handles versioning of Gnulib-imported files is fine. It corresponds to the "middle road" approach, described in the Gnulib manual [2], section "3.13 Integration with Version Control Systems". It is thus supported by Gnulib. > ** Note, for (1) and (2), if you wanted to preserve the ability to > bootstrap from a tarball, you'd have to include gnulib in the > tarball. Of course you could argue that if you are not gnulib-tool > --update'ing, are you really bootstrapping? I don't know the > answer. *** Simon Josefsson is working with the Debian people on this approach. [3] > 3. Fix autopoint to not overwrite newer m4 files with its copies. I > don't know? This is done through the attached patch. > 4. Fix installed gettext to not define gl_ macros ? That would make > it so that it won't stomple on a local gnulib copy. I don't know > though. > > 5. Update to whatever version of gnulib is the latest without this > change? > > 6. Something else? Given that the attached patch works, you don't need to consider these other approaches. Note, though, that the imported po/ infrastructure will still be from 2010, due to this line in configure.ac: AM_GNU_GETTEXT_VERSION([0.18.1]) It would be reasonable to bump this version specification to AM_GNU_GETTEXT_VERSION([0.19.8.1]) (from 2016) or AM_GNU_GETTEXT_VERSION([0.20.2]) (from 2020) or AM_GNU_GETTEXT_VERSION([0.21.1]) (from 2022). Note also that when upgrading to a newer Gnulib, you now have another choice than Gnulib's 'master' branch: the 'stable-202401' branch. See the Gnulib documentation [2], section "1.6.1 Stable Branches". Bruno [1] https://lists.gnu.org/archive/html/bug-standards/2024-05/msg00013.html [2] https://www.gnu.org/software/gnulib/manual/html_node/index.html [3] https://lists.gnu.org/archive/html/bug-gnulib/2024-05/msg00124.html
>From f67b9b9953827dd23b1f71855d057323530bed98 Mon Sep 17 00:00:00 2001 From: Bruno Haible <br...@clisp.org> Date: Mon, 24 Jun 2024 18:53:06 +0200 Subject: [PATCH] Fix conflict between Gnulib and gettext's autopoint program. * autogen.sh: Arrange to not invoke autopoint. --- autogen.sh | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/autogen.sh b/autogen.sh index 2e39fb5d8..f9ece0f24 100755 --- a/autogen.sh +++ b/autogen.sh @@ -33,6 +33,11 @@ echo "" ###################################################################### ### update infrastructure +# Avoid running GNU gettext's autopoint program at this stage, because +# it would overwrite some *.m4 files from Gnulib. See the Gnulib manual +# <https://www.gnu.org/software/gnulib/manual/html_node/index.html> +# section "Caveat: gettextize and autopoint users". +AUTOPOINT=true \ autoreconf -i --force --verbose echo "Now run configure and make." -- 2.34.1
