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
Description: PGP signature
