Re: what to do about gnulib

[Bruno Haible]

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

0001-Fix-conflict-between-Gnulib-and-gettext-s-autopoint-.patch
Description: Text Data