failure building groff with OpenBSD bmake (was: groff 1.24.0.rc1 available for evaluation)

"G. Branden Robinson" <[email protected]> Mon, 19 Jan 2026 12:03:25 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260119180325.mvc2f7jyors5efz4@illithid>
Hi Ingo,

At 2026-01-19T11:55:49+0100, Ingo Schwarze wrote:
[...]
> So, here is the second problem report.  For now, i'm lazily quoting
> my preliminary commit message in the WIP port:
> 
>  ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----
> commit 63d225ba7e1a90988645fbec0d2e599c4732bb22
> Author: Ingo Schwarze <[email protected]>
> Date:   Mon Jan 19 11:15:42 2026 +0100
> 
>     disable parallel builds for now
>     
>     Groff builds have a long history of blowing up in parallel mode,
>     so let's first try to build at all before worrying about broken
>     dependency rules and trying to get parallel building to work.

We've fixed multiple bugs in this respect since groff 1.23.0, and builds
routinely work for me using 10 to 12 cores in parallel.

https://savannah.gnu.org/bugs/?67754
https://cgit.git.savannah.gnu.org/cgit/groff.git/commit/?id=081b89a1dad341b7dc91b98b75ae8f57ec9ea5e5
https://savannah.gnu.org/bugs/?64695

>     Right now, a parallel build dies instantly with:
>     
>     cp -f ./font/devpdf/SS.in font/devpdf/SS
>     make: don't know how to make font/devpdf/symbolsl.afm
>           (prerequisite of: font/devpdf/stamp)
>     Stop in /usr/ports/pobj/groff-1.24.0rc1/groff-1.23.0.5077-7dcc8
>     
>     I hope to investigate later and report properly, this is clearly
>     not a very useful report.  For now: as soon as i remove -j
>     from the make flags, the instant crash goes away and the build
>     progresses a bit further

I saw a similar problem just the other day when using Debian's
superannuated version of bmake.  Parallelism per se was not the problem.

https://lists.gnu.org/archive/html/groff/2026-01/msg00027.html

Because your build is failing on one of the exact same two files mine
did, I suspect something other than parallelism is the culprit here, and
that going single-core is masking the problem.

Please review the "devpdf.am" file and advise if you see any
mistakes.[1]

> The reason for not investigating properly at once is that i worry
> that if i do everything properly, testing might end up taking weeks.
> For 1.23, it ended up taking two years

Unfortunate.  I haven't seen any follow-up from you on ... oh.

Well, I was going to point here:

https://github.com/ischwarze/groff-port/commits/1.23/?after=90725d710b9b2a12af22c7f8fdb8a35959297765+34

...but it looks like you make have force-pushed since our earlier
conversations.  Does that wipe out the comments we'd made?  I recall
offering several back in September.  I guess since they were associated
with Git hashes that are now orphaned, that they did.

Glad to see you made headway here, though!

Incidentally, your feedback on 1.23 prompted me to take a deep dive into
the grammar of delimiters in *roff.  Not just GNU troff, but all *roffs.

Will it surprise anyone if I observe that they were underspecified?

I've now specified them.  Some mandoc test cases may feel the effect.

> - with my now improved testing methodology, i hope it won't get as bad
> as that again, but still, given the history of groff builds, it would
> be unwise to not try to speed up as much as possible, even at the
> expense of making reports feel offensively lazy.  That seems the only
> way to maximize the number of issues found before release.

Your approach is okay with me.  If it becomes too painful or burdensome,
we'll just have to coöperate in finding some mechanism that will ease
the discomfort.

Again, bottom line, I suspect that what you've found is not a
parallelism bug, but either a bug in bmake or a bug in "devpdf.am".

Were you building in-tree or out-of-tree?

Regards,
Branden

[1] https://cgit.git.savannah.gnu.org/cgit/groff.git/tree/font/devpdf/devpdf.am?id=7dcc8b53f944178d91b0f25b67ac32d4f98d9049
signature.asc (application/pgp-signature, 833 B)