URL:
<https://savannah.gnu.org/bugs/?60035>
Summary: build failure on macOS
Project: GNU troff
Submitted by: gbranden
Submitted on: Wed 10 Feb 2021 07:26:01 PM UTC
Category: None
Severity: 4 - Important
Item Group: Build/Installation
Status: In Progress
Privacy: Public
Assigned to: gbranden
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Details:
A generalization of bug #59276.
See thread beginning at:
https://lists.gnu.org/archive/html/groff/2021-02/msg00018.html
and especially T. Kurt Bond's analysis at:
https://lists.gnu.org/archive/html/groff/2021-02/msg00043.html
Here's the body of the final message inline so this report has some direct
context.
It turns out that Dave Kemper <saint.s...@gmail.com>'s suggestion that it
was related to bug 59276
(http://savannah.gnu.org/bugs/index.php?59276) was correct.
I use Homebrew <https://brew.sh/> on macOS to install Unix packages
(instead of macports). I recently did a "brew cleanup", which removes
old versions of packages. This broke the brew installed groff, because it
depended on an older version of ghostscript that had been "cleaned up". So
I tried "brew install -s groff" where the "-s" tells it to install from
source and it built correctly. I noticed that it was patching several files
in the process. I remembered that I'd tried building groff 1.22.4 from the
release tarball recently and it had *not* built correctly.
So I looked at the patch Homebrew was using (which you can find here
<https://raw.githubusercontent.com/Homebrew/formula-patches/8059b3027a4aa68d8f42e1281cc3a81449ca0010/groff/1.22.4.patch>
online) and found that the *only* thing that it does is add '#include
"config.h"' to the following files:
src/libs/libgroff/assert.cpp
src/libs/libgroff/errarg.cpp
src/libs/libgroff/error.cpp
src/preproc/eqn/eqn.ypp
*src/libs/libgroff/curtime.cpp*
src/libs/libgroff/device.cpp
src/libs/libgroff/fatal.cpp
src/libs/libgroff/string.cpp
src/libs/libgroff/strsave.cpp
src/preproc/eqn/text.cpp
src/preproc/eqn/other.cpp
src/preproc/pic/object.cpp
(Well, in some of those it adds '#ifdef HAVE_CONFIG_H/#endif' lines around
the include of config.h, but in others it doesn't.)
The file src/libs/libgroff/curtime.cpp is where the error shows up in my
build.
So I cloned a fresh copy of the groff git repo, applied the patch, and
didn't apply the hunks for that already had that '#include "config.h"' line
in them (src/libs/libgroff/assert.cpp, src/libs/libgroff/errarg.cpp,
src/libs/libgroff/error.cpp, and src/preproc/eqn/eqn.ypp). But the
following files did get patched:
src/libs/libgroff/curtime.cpp
src/libs/libgroff/device.cpp
src/libs/libgroff/fatal.cpp
src/libs/libgroff/string.cpp
src/libs/libgroff/strsave.cpp
src/preproc/eqn/text.cpp
src/preproc/eqn/other.cpp
src/preproc/pic/object.cpp
I then ran bootstrap, configure, and make and the build finished without an
error. Then a make check worked fine. I did a make install, which I'd
configured to install to a particular directory, added that directory to
the front of PATH and rebuilt one of my documents. It looked fine.
The link Dave Kemper pointed to -
https://www.gnu.org/software/gnulib/manual/html_node/Source-changes.html -
points out that that any source file that includes a '-I' that refers to
the Gnulib source directory needs to have ‘#include <config.h>’ at the
top. (I'll note that the patch discussed above consistently uses '#include
"config.h"' instead of "#include <config.h>". ) I looked briefly at the
Makefile to see if I could figure out which files those should be, since
the output of make doesn't actually include the exact command executed, but
I'm not familiar with automake and figuring it out looked difficult for
me.
I briefly looked at how Macports <https://www.macports.org/> does it, and
the patch file
<https://github.com/macports/macports-ports/blob/master/sysutils/groff/files/patch-implicitly-defined.diff>
it uses just adds '#include <config.h>' to lib/math.in.h instead, which
seems like changing the gnulib source instead of changing the groff source
that uses gnulib, which doesn't seem like the right thing to do.
Anyway, I hope this explains the problem and the possible solution
understandably.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?60035>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
