Re: groff 1.24.0.rc1 available for evaluation

  I once used the Gnulib module "posix-check" to find out what could be
improved.

  See bug-groff bugs #61832 and #61833.

  I have these additional Gnulib modules in my bootstrap.conf:

  vsnprintf-posix
  gen-header
  mkstemp
  getcwd
  strerror
  strtol
  assert
  assert-h
  idx
  string-h
  strings-h
  nullptr
  signal-h

  execvp
  faccessat
  fclose
  fdopen
  fflush
  fopen
  freopen
  fseeko
  ftello
  ldexpl
  nl_langinfo
  pclose
  popen
  pthread-mutex
  pthread-once
  pthread-rwlock
  setlocale
  strsignal
  tmpfile

  copysign
  printf-posix
  sprintf-posix
  malloc-gnu
  stack-trace
  abort-debug
  std-gnu23
  bool
  once

  stdcountof-h

  stdio-h

_._

  "groff" is a "GNU groff", so it is intended for a GNU operation system.

  The Gnulib project is to help using GNU software in other operation
systems.

  Trouble can, may, and should be reported to the "[email protected]"
mailing list to get issues fixed or provided solutions.


On Mon, Jan 19, 2026 at 03:13:58PM +0100, Ingo Schwarze wrote:
> Hi Branden,
> 
> 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 :
> 
> ----- 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
> ld: warning: unicode.cpp(libgroff_a-unicode.o:(to_utf8_string(unsigned int))
> 	in archive libgroff.a): warning: sprintf() is often misused,
> 	please use snprintf()
> ld: warning: symbol.cpp(libgroff_a-symbol.o:(symbol::symbol(char const*, int))
> 	in archive libgroff.a): warning: strcpy() is almost always misused,
> 	please use strlcpy()
> ld: warning: symbol.cpp(libgroff_a-symbol.o:(concat(symbol, symbol))
> 	in archive libgroff.a): warning: strcat() is almost always misused,
> 	please use strlcat()
> 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.
> 
> 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.
> I'm almost certain that would just work instantly out of the box,
> whereas gnulib causes such massive portability problems that it
> takes hours and hours of very difficult work to circumvent.
> 
> ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----
> commit d8ce56fb213f0ad5c49dde34aa2cca727588c073
> Author: Ingo Schwarze <[email protected]>
> Date:   Mon Jan 19 14:38:32 2026 +0100
> 
>     prevent gnulib from crashing while trying to replace printf(3)
>     
>     As expected, the newer gnulib used in groff-1.24 has become even
>     more aggressive disparaging our printf(3) implementation for multiple
>     bad reasons.  Getting it to build at all has become significantly
>     harder.  Notably, the pointless quibbles about errno.h and strerror(0)
>     appear to make gnulib want to replace the entire printf(3)
>     implementation, unless i'm totally misinterpreting what is going
>     on in the build - which might be the case because both the gnulib
>     code and the ./configure code are utterly unreadable: the former
>     because of its totally excessive use of #if directives, the latter
>     because it has no indentation whatsoever that could help reading
>     it.  So i'm not completely sure this is the minimal fix, though it
>     does look like every single one of the seven tweaks is really
>     required.
>     
>     With this fix, the build progresses slightly further.
>     Now grodvi builds; it's now grops that explodes.
> 
> diff --git a/Makefile b/Makefile
> index 856f70a..859454c 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -68,15 +68,20 @@ CONFIGURE_ARGS +=	PAGE=letter
>  # from gnulib.  In particular, groff does not use %n, so it would be
>  # insane to use an implementation that lacks our %n protection.
>  CONFIGURE_ENV +=	gl_cv_func_printf_directive_a=yes \
> +			gl_cv_func_printf_directive_b=yes \
>  			gl_cv_func_printf_directive_n=yes \
> -			gl_cv_func_printf_enomem=yes
> +			gl_cv_func_printf_enomem=yes \
> +			gl_cv_func_printf_sizes_c23=yes \
> +			gl_cv_func_strerror_0_works=yes \
> +			gl_cv_header_errno_h_complete=yes
>  
>  # Disable dependencies of the gnulib fprintf-posix module.
>  # Even though we tell ./configure that our fprintf(3) shall be used,
>  # gnulib is too stupid to understand that implies the dependecies
>  # aren't needed either und would still compile in needless and
>  # potentially risky printf(3) code from gnulib.
> -CONFIGURE_ENV +=	ac_cv_func_vasnprintf=yes
> +CONFIGURE_ENV +=	ac_cv_func_vasnprintf=yes \
> +			gl_cv_func_vasnprintf_works=yes
>  
>  # Even after the above CONFIGURE_ENV cleanup, gnulib compiles in
>  # several bogus files that groff does not need, merely because
> ----- 8< ----- schnipp ----- >8 ----- 8< ----- schnapp ----- >8 -----
> 
> Yours,
>   Ingo
>