Hi Richard, At 2026-07-28T14:15:12+0100, Richard Purdie wrote: > I reported some build races a while ago. It appears there are still > some issues left and they weren't an isolated problem. I tried to make > a simple reproducer for the original problem I ran into but ran into > further problems. To illustrate what I saw (on a fresh checkout of > groff from git):
[snipping the initial Gnulib-produced header issue with which I requested aid] > make doc/groff-man-pages.pdf > GROFF doc/groff-man-pages.pdf > /groff/groff: error: couldn't exec preconv: No such file or directory > pdfmom: fatal error: test-groff exited with status 16 > make: *** [Makefile:19752: doc/groff-man-pages.pdf] Error 1 > make: *** Deleting file 'doc/groff-man-pages.pdf' > > which leads me to believe this is needed: > > diff --git a/doc/doc.am b/doc/doc.am > index 9898a19d8..a30b3e599 100644 > --- a/doc/doc.am > +++ b/doc/doc.am > @@ -289,7 +289,7 @@ $(DOC_GMP_COVER_PAGE): > $(doc_srcdir)/groff-man-pages-cover.groff.in > > doc/groff-man-pages.pdf: $(GROFF_MAN_PAGES_ALL) \ > $(DOC_GMP_COVER_PAGE) \ > - eqn pic tbl pdfmom \ > + eqn pic tbl pdfmom preconv \ > $(TMAC_PACKAGE_MAN) $(TMAC_PACKAGE_MDOC) font/devps/freeeuro.pfa > $(GROFF_V)$(DOC_PDFMOM) -K utf-8 -pet -mandoc -dHF=HB -rC1 \ > -rCHECKSTYLE=3 -Tpdf $(groffmanpagesoption) \ > @@ -298,7 +298,7 @@ doc/groff-man-pages.pdf: $(GROFF_MAN_PAGES_ALL) \ > $(tmac_srcdir)/sv.tmac $(GROFF_MAN_PAGES2) \ > $(tmac_srcdir)/en.tmac $(GROFF_MAN_PAGES3) > $@ > > -doc/groff-man-pages.utf8.txt: $(GROFF_MAN_PAGES_ALL) eqn pic tbl \ > +doc/groff-man-pages.utf8.txt: $(GROFF_MAN_PAGES_ALL) eqn pic tbl preconv \ > $(TMAC_PACKAGE_MAN) $(TMAC_PACKAGE_MDOC) > $(GROFF_V)$(DOC_GROFF) -K utf-8 -pet -Tutf8 -mandoc \ > -rCHECKSTYLE=3 $(GROFF_MAN_PAGES1) \ Good catch. preconv(1) is certainly required, as groff_mmse(7) is in the set of documents being read by the pipeline. I'll fix this for 1.25.0.rc2. You gave me an idea, which I've filed as <https://savannah.gnu.org/bugs/?68574>. > but there may be further missing dependencies. I'd also note: > > $ make doc/automake.pdf > [...] > GROFF doc/automake.pdf > groff/groff: error: couldn't exec preconv: No such file or directory > groff/groff: error: couldn't exec pic: No such file or directory > groff/groff: error: couldn't exec eqn: No such file or directory > pdfmom: fatal error: test-groff exited with status 24 > make: *** [Makefile:19637: doc/automake.pdf] Error 1 > > which is probably: > > diff --git a/doc/doc.am b/doc/doc.am > index 9898a19d8..47ef1621c 100644 > --- a/doc/doc.am > +++ b/doc/doc.am > @@ -143,7 +143,7 @@ EXTRA_DIST += $(DOCFILES_NOINST) > EXTRA_DIST += doc/automake.mom > docpdfdocdir = $(pdfdocdir) > nodist_docpdfdoc_DATA = $(PROCESSEDDOCFILES_PDF) > -doc/automake.pdf: doc/automake.mom pdfmom $(TMAC_PACKAGE_MOM) > +doc/automake.pdf: doc/automake.mom pdfmom pic eqn preconv $(TMAC_PACKAGE_MOM) > > # GNU PIC html documentation, installed in $(htmldocdir) > # Other pic*.html files are installed by the local rule > > to fix. Those are just the ones we've run into though. The foregoing is an interesting case. We don't actually need preconv, eqn, _or_ pic to generate "automake.pdf". "automake.mom"'s only non-ASCII character appears in a _roff_ comment. https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/doc/automake.mom?h=1.25.0.rc1#n3 It uses no preprocessor tokens, either (`TS`, `EQ`, `PS`, `[`). Yet pdfmom(1), in an effort to be helpful I suppose, brings the full power of its battle station to bear on poor old Alderaan. $ make V=1 doc/automake.pdf /usr/bin/mkdir -p `dirname doc/automake.pdf` \ && LC_ALL=C GROFF_COMMAND=test-groff GROFF_COMMAND_PREFIX= GROFF_BIN_PATH="/home/branden/BUILD/groff-1.25.0.rc1" /home/branden/BUILD/groff-1.25.0.rc1/pdfmom -F/home/branden/BUILD/groff-1.25.0.rc1/font -F/home/branden/BUILD/groff-1.25.0.rc1/font -M/home/branden/BUILD/groff-1.25.0.rc1/tmac -M/home/branden/BUILD/groff-1.25.0.rc1/tmac -M./contrib/mom -K utf8 -p -e -t -wall -b -P-W doc/automake.mom >doc/automake.pdf /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec preconv: No such file or directory /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec pic: No such file or directory /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec tbl: No such file or directory /home/branden/BUILD/groff-1.25.0.rc1/groff: error: couldn't exec eqn: No such file or directory pdfmom: fatal error: test-groff exited with status 16 make: *** [Makefile:19555: doc/automake.pdf] Error 1 make: *** Deleting file 'doc/automake.pdf' However, I have to use a groff-less chroot to reproduce this problem. If I don't, the document build escapes from its enclosure and finds the preprocessors installed in the host environment. That's not good. I perceive 3 independent lines of attack. 1. As I mentioned earlier this month, we don't need to use pdfmom(1) _at all_ to generate "automake.pdf". https://lists.gnu.org/archive/html/groff/2026-07/msg00019.html I can take care of this in the short term for 1.25.0.rc2. 2. Make "test-groff" set "PATH=$GROFF_BIN_PATH" and see what, if anything, breaks. Since "test-groff" is just a wrapper for "groff", and "groff" builds a pipeline _only_ of programs that are produced as part of a groff build, this _should_ work. But I know better than to bet money on it. I'll file a Savannah ticket for this issue and will plan to work on it early in the 1.26 development cycle. If it works out, it should go a good distance toward solving a problem I think Deri observed with groff documentation artifacts getting build not necessarily with the build's groff programs. 3. pdfmom(1)'s mission needs to be put on a diet.[ibid.] It seems to have mutated into a tool with no charter except to get documents built with brute force, multi-pass processing whether they need that or not, throwing several preprocessors at them whether needed or not, and, recently, sprawling beyond its initial goal of easing production of PDF documents using the mom(7) macro package to generating general "roff" documents, not necessarily using mom(7) (see its `--roff`(!) option) or being produced in PDF format. In other words, having disposed of one Perl script called groffer(1) in groff 1.23.0, we are metamorphosing another Perl script into its replacement. Enough! I have some notions of a new approach but they'll need to cook a while longer. I have no concrete timeline for working this out. > It was bad enough someone suggested we should patch groff: > > --- a/Makefile.am~ 2026-05-15 13:23:08.000000000 +0100 > +++ b/Makefile.am 2026-05-15 13:29:17.053867035 +0100 > @@ -556,15 +556,0 @@ > -include $(top_srcdir)/contrib/chem/chem.am > -include $(top_srcdir)/contrib/eqn2graph/eqn2graph.am > -include $(top_srcdir)/contrib/gdiffmk/gdiffmk.am > -include $(top_srcdir)/contrib/glilypond/glilypond.am > -include $(top_srcdir)/contrib/gperl/gperl.am > -include $(top_srcdir)/contrib/gpinyin/gpinyin.am > -include $(top_srcdir)/contrib/grap2graph/grap2graph.am > -include $(top_srcdir)/contrib/hdtbl/hdtbl.am > -include $(top_srcdir)/contrib/install-font/install-font.am > -include $(top_srcdir)/contrib/mm/mm.am > -include $(top_srcdir)/contrib/mom/mom.am > -include $(top_srcdir)/contrib/pic2graph/pic2graph.am > -include $(top_srcdir)/contrib/rfc1345/rfc1345.am > -include $(top_srcdir)/contrib/sboxes/sboxes.am > -include $(top_srcdir)/doc/doc.am > > so that we could avoid these issues! That's not the "right" fix, but I sympathize. > https://git.openembedded.org/openembedded-core/commit/?id=9deeb7474b2586eb031e4f00a644aed9ccf8cb19 > > I wasn't sure if there was a better way to avoid the bits of the build > we don't really need just to get the tools? We have a ticket for this, but you won't _need_ a "tool-only" build if we can keep wrappers like "test-groff" and "pdfmom" from going hunting for tools outside of the build environment when they're run inside it. https://savannah.gnu.org/bugs/?68554 Regards, Branden
signature.asc
Description: PGP signature
