Re: groff 1.24.0.rc1 available for evaluation

"G. Branden Robinson" <[email protected]> Mon, 19 Jan 2026 13:24:27 -0600
Newsgroups	gmane.comp.printing.groff.general
Message-ID	<20260119192427.xvi6wkbteo3kvvf5@illithid>
Hi Ingo,

At 2026-01-19T15:13:58+0100, Ingo Schwarze wrote:
> Here is my third problem report.  I already spent hours of working
> time on this one, performing more than a dozen cycles of adding of
> modifying a tweak, than running the next build attempt, but all these
> attempts crashed at the same place in grodvi/dvi.o :

:(

(Observation: no matter how many cores I use or what OS I build on,
"grodvi" is reliably the first thing that attempts to link.  I guess
that, among the executables groff builds, it has the shallowest branch
in the dependency graph.)

> 
> ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----
> c++  -O2 -pipe    -o grodvi src/devices/grodvi/dvi.o libdriver.a
> 	libgroff.a  lib/libgnu.a -lm
> ld: warning: libgroff.a: archive member 'libgnu.a' is neither ET_REL
> 	nor LLVM bitcode

I know this isn't the problem you're reporting, but I wanted to note for
posterity that I see the foregoing LLVM `ld` warning on _all_ of my
Termux/Android aarch64 builds.  It seems to be harmless.

[linker hectoring about "safe" libc functions snipped]

> ld: error: undefined symbol: vfzprintf
> >>> referenced by fprintf.c
> >>>               libgnu_a-fprintf.o:(rpl_fprintf) in archive lib/libgnu.a
> >>> did you mean: vfwprintf
> >>> defined in: /usr/lib/libc.so.102.2
> 
> ld: error: undefined symbol: rpl_strerror
> >>> referenced by font.cpp
> >>>               libgroff_a-font.o:(font::load(bool)) in archive libgroff.a
> c++: error: linker command failed with exit code 1 (use -v to see invocation)
> *** Error 1 in . (Makefile:8337 'grodvi')
> ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----
> 
> Again, i'm lazily quoting my commit message of the fix in my WIP port,
> for now.

Okay.  I'll forward your this report to bug-gnulib@ and see if they're
willing to help given this limited record.

> It would be incredibly helpful to have a mode to simply build groff
> without gnulib interference.  To have a mode that simply assumes that
> everything groff wants from gnulib is natively available from the
> operating system.  Simply let that "native mode" crash when some
> feature that is actually needed is missing from the operating system,
> and let it be the responsibility of the porter to provide the feature.

If the GNU Autotools affords me an easy "./configure" switch to do this,
I'm happy to promote it for situations like yours/OpenBSD's.

> I'm almost certain that would just work instantly out of the box,

...in well-curated development environments, possibly.

I trust you'll agree with me that those are rare.

> whereas gnulib causes such massive portability problems that it
> takes hours and hours of very difficult work to circumvent.

At the same time I don't want groff doing gnulib's job; I don't think
any groff maintainer ever has.  (Clark didn't have a choice in 1989-91.)

See <https://savannah.gnu.org/bugs/?66518>.

Regards,
Branden
signature.asc (application/pgp-signature, 833 B)