I built groff from a fresh git clone and it built fine. A "make check" ended with:
============================================================================ Testsuite summary for GNU Troff 1.23.0.rc1.204-979f ============================================================================ # TOTAL: 52 # PASS: 49 # SKIP: 0 # XFAIL: 3 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ I installed it and rebuilt one of my documents and it looked fine. Thanks! On Thu, Feb 11, 2021 at 3:31 AM G. Branden Robinson < g.branden.robin...@gmail.com> wrote: > Hi Kurt! > > At 2021-02-10T14:03:42-0500, T. Kurt Bond wrote: > [big snip] > > Thanks a lot for digging into this! I have committed what _seems_ like > should be a fix based on your extensive description. > > > https://git.savannah.gnu.org/cgit/groff.git/commit/?id=979f3f4266151c7681a68a40d2c4913842a7271d > > If any macOS users with experience building groff (or the ambition to > start) would like to try it out, please do and let us know how it works > out, here or to the bug. > > https://savannah.gnu.org/bugs/index.php?60035 > > I dithered a little bit (probably unnecessarily) over the angle-brackets > versus quotation marks issue. I'm used to thinking in terms of the > following dichotomy: > > * if you expect the compiler to find the header for you without a -I > flag, use <foo.h>; and > * if you need to specify an -I flag to tell the compiler where to find > the header, use "foo.h". > > But after consulting some exegeses of ISO C standard I am less certain. > The possibility of "header files" that aren't really on-disk source > files is something I had heard of but not had to deal with in practice. > On the other hand, the notion that an autoconf-generated config.h could > possibly be such a thing is wholly unfamiliar. But, it's what the > gnulib manual insists upon, so I went with it. > > Regards, > Branden > -- T. Kurt Bond, tkurtb...@gmail.com, https://tkurtbond.github.io
